文 / 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集成来构建什么，但是我无法在这些测试中评估这些。