自去年4月Firefox 53刪除NPAPI以來，該插件一直無法被正常訪問。而就在去年年末，Google Hangouts（環聊）重新支持使用Firefox WebRTC。本文深度剖析了Firefox SDP并比較了Firefox和Chrome Hangouts的WebRTC規范。?

作者：Philipp Hancke?

翻譯：鴻蒙

Tsahi發現Firefox上的環聊再次開始工作，并迅速呼叫Fippo進行調查。

在2017年的末尾，Google Hangouts（環聊）開始重新支持Firefox。自2017年4月Firefox 53刪除NPAPI以來，該插件一直無法正常訪問。盡管Firefox WebRTC團隊測試Hangouts的事情已經公開了一段時間，但看到它付諸實際仍然是一件很令人興奮的事情。 Tsahi Levent-Levi是最先注意到的人之一。Hangouts 團隊用實際行動表示他們仍然視網絡為一個開放的平臺！

我此前在2014年寫過一篇關于Hangouts的文章（https://webrtchacks.com/hangout-analysis-philipp-hancke/），Hangouts使用了很多非標準技術，如SDES和RTP DataChannel——它們不支持Firefox，而是否支持Firefox往往是一個很重要的產品技術指標（也有傳言說是因為它的NaCl和'hats'特征，正如我在舊博客中提到的那樣）。

不過，當視頻Hangouts 產品的會議功能作為其不斷現代化的一部分時，事情已經起了變化。例如，Opus早已成為默認的音頻編解碼器。雖然Chrome中的Hangouts 并非100％與WebRTC 1.0規范兼容（例如，我已經看到Chrome使用DTLS-SRTP而不是SDES），但Firefox實現似乎有點不同，并且更符合標準：

FireFox Hangouts和Chrome Hangouts WebRTC規范比較

深入剖析SDP

讓我們來深入剖析SDP。不幸的是自從FF57以來，Firefox中的webrtc-externals擴展已被打破，沒有人有時間弄清楚為什么。 但是我們從about:webrtc中得到的SDP實際上非常有意思：

1v=0
2o=mozilla...THIS_IS_SDPARTA-57.0.1 8208570803153758710 3 IN IP4 0.0.0.0
3s=-
4t=0 0
5a=sendrecv
6a=fingerprint:sha-256 79:67:68:53:C0:3C:4D:60:1B:DD:D5:FE:BA:D0:86:3C:30:44:FE:4B:14:CB:ED:E4:D3:21:22:88:F9:25:F2:F5
7a=group:BUNDLE mid_0 mid_1 mid_2 mid_3 mid_4
8a=ice-options:trickle
9a=msid-semantic:WMS *
10m=audio 37842 UDP/TLS/RTP/SAVPF 109
11c=IN IP4 84.20.98.117
12a=candidate:0 1 UDP 2122252543 192.168.1.230 37842 typ host
13a=candidate:3 1 TCP 2105524479 192.168.1.230 9 typ host tcptype active
14a=candidate:1 1 UDP 1686052863 84.20.98.117 37842 typ srflx raddr 192.168.1.230 rport 37842
15a=sendrecv
16a=end-of-candidates
17a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
18a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
19a=ice-pwd:72af2dc778d255334cb38661e30fc57a
20a=ice-ufrag:80e16c7c
21a=mid:mid_0
22a=msid:{7a66c1a7-b588-4d8d-ab7c-92cb4a248aea} {1dda5d9f-d705-4db7-bfb1-1153833be2a4}
23a=rtcp-mux
24a=rtpmap:109 opus/48000/2
25a=setup:active
26a=ssrc:490004612 cname:{90bfee9f-4610-43b0-993f-a064332e442b}
27m=video 37842 UDP/TLS/RTP/SAVPF 120
28c=IN IP4 84.20.98.117
29a=sendrecv
30a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
31a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
32a=fmtp:120 max-fs=12288;max-fr=60
33a=ice-pwd:72af2dc778d255334cb38661e30fc57a
34a=ice-ufrag:80e16c7c
35a=mid:mid_1
36a=msid:{444747d4-c2d2-45ce-a761-c572c0648e18} {6030f14c-68c2-4f35-8803-af7011d4bbb8}
37a=rid:f send
38a=rid:h send
39a=rid:q send
40a=rtcp-fb:120 nack
41a=rtcp-fb:120 ccm fir
42a=rtcp-fb:120 goog-remb
43a=rtcp-mux
44a=rtpmap:120 VP8/90000
45a=setup:active
46a=simulcast: send rid=f;h;q
47a=ssrc:944082137 cname:{90bfee9f-4610-43b0-993f-a064332e442b}
48a=ssrc:3093937015 cname:{90bfee9f-4610-43b0-993f-a064332e442b}
49a=ssrc:3682296736 cname:{90bfee9f-4610-43b0-993f-a064332e442b}
50m=application 37842 DTLS/SCTP 5000
51c=IN IP4 84.20.98.117
52a=sendrecv
53a=ice-pwd:72af2dc778d255334cb38661e30fc57a
54a=ice-ufrag:80e16c7c
55a=mid:mid_2
56a=rtcp-mux
57a=sctpmap:5000 webrtc-datachannel 256
58a=setup:active
59a=max-message-size:1073741823
60m=audio 37842 UDP/TLS/RTP/SAVPF 109
61c=IN IP4 84.20.98.117
62a=recvonly
63a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
64a=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
65a=ice-pwd:72af2dc778d255334cb38661e30fc57a
66a=ice-ufrag:80e16c7c
67a=mid:mid_3
68a=rtcp-mux
69a=rtpmap:109 opus/48000/2
70a=setup:active
71a=ssrc:2828437981 cname:{90bfee9f-4610-43b0-993f-a064332e442b}
72m=video 37842 UDP/TLS/RTP/SAVPF 120
73c=IN IP4 84.20.98.117
74a=recvonly
75a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
76a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
77a=fmtp:120 max-fs=12288;max-fr=60
78a=ice-pwd:72af2dc778d255334cb38661e30fc57a
79a=ice-ufrag:80e16c7c
80a=mid:mid_4
81a=rtcp-fb:120 nack
82a=rtcp-fb:120 ccm fir
83a=rtcp-fb:120 goog-remb
84a=rtcp-mux
85a=rtpmap:120 VP8/90000
86a=setup:active
87a=ssrc:3511641524 cname:{90bfee9f-4610-43b0-993f-a064332e442b}

我們可以從中學到很多東西，所以我們來深入研究一下。有關WebRTC SDP的更深入的綜述，請查看SDP Anatomy指南。

RTP有效負載類型（payload type）

1a=rtpmap:109 opus/48000/2

Firefox主動創建請求，這意味著它為音頻和視頻數據包選擇使用RTP有效負載類型，并且服務器需要對每個數據包進行重寫。這是相當瑣碎的工作，需要開發人員的努力。

同時聯播（Simulcast）

1a=simulcast: recv rid=f;h;q
2a=rid:f recv
3a=rid:h recv
4a=rid:q recv
5a=extmap:3/recvonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id

a=rid ?和?a=simulcast 這幾行表示使用同時聯播， Firefox并沒有在這里實現最新的IETF草案，但與Chrome不同，它不需要SDP改寫，而依靠RTCRtpSender.setParameters。 如果您對使用情況感興趣，Firefox會進行單元測試，顯示基本使用情況。 這當然比SDP改寫更好（盡管它仍然是我們都害怕的SDP）。在網絡上，Firefox同時聯播使用RID頭擴展來“標記”不同的視頻流。

在FF57之前，Firefox同時聯播并不是非常穩定，這可能因為FF57進一步詮釋了時機。

REMB

1a=rtcp-fb:120 goog-remb

Firefox使用REMB 進行帶寬估算，而不是其尚未支持的更新的transport-cc機制。 在Chrome中使用transport-cc表示它在服務器中就被終止了。可能要花費很大的努力才能將兩者很好地結合在一起，因為帶寬估計是WebRTC中最難的問題之一。

SCTP數據通道

1m=application 9 DTLS/SCTP 5000

我們看到在 m=application ?媒體部分, 使用了SCTP 數據通道。這是相當程度的工程設計工作，但可能是由于RTP數據通道不能與DTLS-SRTP一起工作，才作為Meet早期的全面檢修的一部分。 這也表明通過數據通道發送的控制消息很重要。 不幸的是，它們是原始編碼的，所以比較難以理解。

統一計劃（Unified Plan）

1m=audio 9 UDP/TLS/RTP/SAVPF 109 0

最有趣的是使用有5條m線的 “Unified Plan” SDP (已經融入 JSEP)。 Chrome中缺乏統一計劃顯然不是問題。這并不令人感到意外，如果您想使用單個PeerConnection，您可以將SDP簡單地改寫為瀏覽器所需的任何格式。 Jitsi已經在sdp-interop包中做了這么多年了。檢查這個操作是發生在客戶端的javascript還是服務器上會很有趣。

SDP中缺少的東西也很有趣。由于Firefox不支持RTX，ulpfec和red，因此服務器需要打開這些數據包并選擇丟棄它們，或者像RTX那樣，將它們轉換回正常的RTP數據包。根據我的經驗，這遠不是微不足道的。

ice-lite

1a=ice-lite

在服務器SDP中，我們還發現ice-lite是RFC 5245允許的ICE簡化版本，非常適合具有公共IP地址且易于實現的媒體服務器。前段時間，Hangouts 從google-ice 轉移到了 ice-lite。可以在about:webrtc查看完整的細節。

WebRTCon 2018 8折報名

WebRTCon希望與行業專家一同分享、探討當下技術熱點、行業最佳應用實踐。如果你擁有音視頻領域獨當一面的能力，歡迎申請成為講師，分享你的實踐和洞察，請聯系 speaker@livevideostack.com。更多詳情掃描下圖二維碼。

總結

以上是生活随笔為你收集整理的Google Hangouts支持使用Firefox WebRTC的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。