正文字數：3144 ?閱讀時長：4分鐘

本文來自Housepaty的軟件工程師Gustavo Garcia，他對Azure通信服務（ACS）進行了全面的評估，包括從瀏覽器兼容性、編解碼器到帶寬估計算法…..與主要對手相比成熟度還有差距。

文?/?Gustavo Garcia

譯?/?Helen Lyu

原文鏈接 /?https://webrtchacks.com/how-does-azure-communication-services-implement-webrtc-gustavo-garcia/

我們在分析使用WebRTC的主要服務方面有著悠久的傳統。在網頁即時通信處于成功狀態后，我們跟不上列表增長的速度。幸運的是，我們最喜歡的作家之一Gustavo Garcia Bernardo最近找到了時間來審查新的Microsoft Azure通信服務。他發現了一些有趣的結果，我們很高興在這里展示。Gustovo在實時通信方面有著深厚的職業經驗，并且自WebRTC成立之初就一直密切參與著。

每當有1.6萬億美元的公司進行產品發布時，通常都是一件大事，尤其是對于那些定期處理通訊API的人而言。微軟和WebRTC有著悠久而獨特的歷史，因此我們特別想知道（微軟）如何將WebRTC用作此新產品的一部分。

如你所見，這也有一些有趣的特性。幾周前，Microsoft宣布了Azure通信服務（ACS）。他們的云服務目錄中的此新產品提供聊天，SMS，PSTN呼叫和視頻通信。

它在通信平臺即服務（CPaaS）類別中與Vonage，Twilio，Agora等主要參與者競爭，并與Zoom或Amazon的視頻API產品競爭。這款微軟的產品與其競爭對手沒有太大的不同。這篇文章將重點介紹語音和視頻部分。這些基于WebRTC。

如在后面顯示的詳細信息中所見，它重用了很大一部分現有的Microsoft基礎結構（來自Skype和/或Microsoft Teams）。在較高級別上，有2種API：

1. 管理API –包括用于創建用戶和訪問令牌的服務器端SDK

2. 客戶端SDK –適用于Web，Android和iOS，可將端點連接到通信服務器，以發送和接收來自PSTN和Microsoft Teams的音頻/視頻/屏幕共享以及媒體。

API和它提供的功能

客戶端API中有兩個基本原語：呼叫和房間。使用“呼叫”界面，您可以呼叫連接到系統的任何其他用戶。使用“房間”原語，您可以加入房間。（客戶端API）對身份和呼叫的支持比其他平臺更強，這可能是因為基礎結構被重用并且該功能提供了與Teams平臺的集成。

房間訪問權限的缺乏很有意思，（因為）如果知道房間ID，則每個訪問令牌顯然都具有加入每個房間的權限。

在客戶端，除了一些音頻和視頻設備管理API之外，還提供了基本的呼叫控制操作（靜音/取消靜音，保持/取消保持，屏幕共享），以簡化系統配置。

WebRTC合規

作為總結，讓我們比較一下Azure在這種情況下使用的地方與WebRTC標準（W3C或各種IETF草案）有何不同：

客戶端SDK

該客戶端SDK適用于Web，iOS和Android。目前，瀏覽器支持有限。它僅包括Chrome，對Safari的部分有限支持（僅接收），以及僅基于Windows的新款基于Chromium的Edge。

在測試Web和Android SDK時，值得注意的是它們仍然需要改進。例如，瀏覽器日志顯示了非常冗長的控制臺，以及與統計信息或某些請求失敗有關的常見警告，盡管這對于第一個版本是預期的。

服務器端管理SDK

Microsoft提供了用于創建用戶和令牌的管理SDK，以支持C#，Python，Java和Node.js。這些SDK將在受信任的應用程序中運行，并且需要在Azure控制臺中創建的訪問密鑰。Microsoft通過支持主訪問密鑰和輔助訪問密鑰來支持訪問密鑰旋轉而獲得加分。

其他特性

其他一些高級功能：

1. PSTN呼叫：專用預覽版不允許我們對此進行測試，但是根據文檔（里面講述的），它支持1：1呼叫和組呼叫。

2. SMS –如上所述，我們無法對此進行測試，但是發送和聊天也是Azure通信產品的一部分。

3. Teams集成：這也是Private Preview中的功能，但隨著當今Teams產品的普及，該新的通訊平臺可能會受到最初的關注，這是一種使用案例。

在文檔或SDK中沒有提及記錄或廣播功能，也沒有與Azure流處理功能（如文本到語音或視覺API）進行任何集成。

發信號

信令基于HTTP請求。

人們可以在信號中看到許多對Skype域的引用，這些信號表明如何在Microsoft生態系統的其他現有部分之上使用此產品。

實際上，甚至Azure Comms Services的JWT令牌內的用戶標識符稱為skypeids：

以下是當您使麥克風靜音/取消靜音時基于HTTP的自定義JSON格式的專有信令示例：

對于1：1呼叫，系統使用直接的P2P WebRTC連接.在“房間”模式下，ACS使用SFU在不同參與者之間轉發音頻和視頻數據包。這些SFU位于不同的區域。就我而言（在歐洲），我在考試期間被分配到都柏林的一個（SFU）。

SDP和媒體

對等連接計劃

客戶端SDK使用單個WebRTC PeerConnection來發送和接收多個流。這是最高效，最現代的機制，但并非所有平臺都使用。不利的一面是，它使用原始的Plan-B語義而不是新的Unified Plan語義。考慮到Plan-B的存在，這并不是非典型的。（直到）今天，許多最大的多方應用程序仍在使用Plan-B。

交互式連接建立（ICE）

在媒體連接方面，ACS同時使用STUN和TURN TCP服務器。

令人驚訝的是，（它并）未包括TURN TLS –這可能會限制ACS在受限企業環境中進行連接的能力。

http://localhost:5000/, { iceServers: [turn:52.158.34.11:3478?transport=udp, turn:52.158.34.11:443?transport=tcp], iceTransportPolicy: all, bundlePolicy: max-bundle, rtcpMuxPolicy: require, iceCandidatePoolSize: 0, sdpSemantics: "plan-b" }, {advanced: [{enableDtlsSrtp: {exact: false}}, {googCpuOveruseDetection: {exact: false}}]}

為了直接連接到SFU，它使用典型的ICE UDP候選對象，但也使用端口3478中的ICE TCP候選對象。ICE的支持不是ice-lite，而是full ice在帶有公共IP的SFU中，這不是很常見，因為它很難實現。Full ICE并沒有提供很多優勢，但也沒有任何負面影響。

加密

WebRTC要求的加密是基于SRTP。但是，SFU /房間密鑰交換使用的是SDES，而不是標準的DTLS協議。這樣比較簡單，可以提供更快的建立速度，但僅Chrome支持。由于該標準明確禁止SDES，因為它不如標準DTLS要求安全，因此可能會在某個時候將其刪除。

Codecs

G.722用于音頻編解碼器。對于WebRTC平臺，這確實不常見，但是鑒于PSTN互操作性的需求和現有Microsoft基礎結構的重用，這并不令人驚訝。這是帶有音頻通道信息的SDP答案的一部分：

m=audio 3480 RTP/SAVPF 9 0 8 13 101

c=IN IP4 40.113.83.182

a=rtpmap:9 G722/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:13 CN/8000

a=rtpmap:101 telephone-event/8000

The video codec selected in H.264.

在H.264中選擇的視頻編解碼器。它使用RTX重傳來確保可靠性。ACS不包括聯播支持，以使視頻質量適應會議室中不同參與者的需求。同樣至少在我測試的示例中，比特率非常低。你可以從發送者參數的下一個捕獲中看到如何將其配置為以200kbps使用H264。

RTCP

RTP / RTCP級別上的其他一些細節是大多數平臺中也使用了bundle，rtcp-mux和rtcp-rsize的用法。它還為每個流（1501、1551…）保留50 ssrc，并且在呼叫的初始建立期間，在遠程SDP中為將來的參與者預分配了8個遠程流。

帶寬估算（BWE）

對于帶寬估計，它使用接收方支持（基于REMB），而不是更現代，更優化的發送方帶寬估計（基于傳輸反饋）。

其他身份不明的東西

SDP中還存在非標準擴展。我懷疑它們是否會產生影響，并且可能會繼承自其他應用程序。例如：

a=x-mediabw:applicationsharing-video send=8000;recv=8100

a=x-source-streamid:19

a=x-signaling-fb:* x-message app send:dsh

a=x-signaling-fb:* x-message app send:src,csrc,vc recv:src

結論

Azure Communication Services具有一個簡單的API。一切工作都符合預期并且很輕松。該文檔很好，交互式示例確實很有幫助。它還保證了一種易于理解和具有競爭力的定價模型。另一方面，這仍然是Beta產品它不會像已經存在多年的競爭對手提供的那樣成熟。如果要認真考慮ACS，Microsoft必須將支持擴展到其他瀏覽器，并清除現有的Web支持

此外，缺少一些視頻質量技術（主要是聯播）和缺乏對較新編解碼器（特別是Opus）的支持是在預期以外的，希望Microsoft即將發布的版本可以解決這些問題。

對于許多流行的用例來說，缺少記錄也是一個很大的差距。在我看來，最有希望的部分是與Azure生態系統潛在集成的功能，如推送通知，文本到語音轉換，計算，發布訂閱...例如，擁有發布訂閱支持音頻/視頻會非常有用，但是 目前僅適用于SMS。

我也很期待人們可以使用Teams集成來構建什么，但是我無法在這些測試中評估這些。

LiveVideoStackCon 2020 SFO（線上峰會）

我們提出了一種稱為“視頻矢量化”的新型視頻壓縮算法。

視頻矢量化將視頻轉碼為一個矢量圖形格式，并利用SVG和OpenGL等開放標準和現有標準在用戶設備上進行渲染。

這樣做可以使用開放標準和現有標準以便壓縮動畫和截屏視頻內容十倍。

LiveVideoStackCon 2020?美國舊金山站

北京時間：2020年12月11日-12月13日

點擊【閱讀原文】訪問直播頁面

總結

以上是生活随笔為你收集整理的新的Azure通信服务（ACS）如何实现WebRTC？的全部內容，希望文章能夠幫你解決所遇到的問題。

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