HaaS RTC（实时音视频通信）总体方案简介

桃扇骨 2022-10-04 13:56 382阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70][]

# **一、RTC业务简单介绍** #

RTC（Real Time Communication）实时通信业务，目的是在设备端实时的转发音视频多媒体数据，让用户能实时的进行音频和视频的会话。通信业务一般都有如下几个部分组成：

*  呼叫信令：用于呼叫的应答和协商，主叫和被叫之间要协商是否建立呼叫、数据通道的连接参数、数据格式、数据类型等信息，让主叫和被叫之间对齐音频编码、视频编码的相关信息，这样才能进行音频和视频的编解码-传输流程。。
 *  数据传输：基于呼叫信令协商好的参数进行音视频数据的采集-编码-传输-解码-展示。

*  数据传输控制：反馈传输通道的情况，确认传输通道质量，同时音视频同步参数。

实时通信业务基本上分为两种形态：

**点对点**：通行双发设备具体直连的通道，在两个设备端之间直接处理信令呼叫和数据传输。主叫和被叫之前必须使用相同的音视频编码参数、音频打包时长等信息。采用的是对等的传输通道。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 1][]

**中心化交换**：有两个方式，**只是信令的中心化交换**，**信令和数据都中心化交换**。

信令中心化交换，只是通过服务器控制呼叫信令的转发，服务器不参与音视频数据传输。服务器不需要投入很多资源，只是管理设备状态、业务鉴权，音视频数据的传输完全由设备点对点完成。服务器只保证信令通道的QoS。

信令和数据都中心化交换：服务器要负责信令的转发，同时要负责所有音视频数据的转发。服务器既要完成信令的转发，还要负责音视频数据的转发，服务器需要的资源随多媒体的采样率、格式、分辨率变化。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 2][]![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 3][]

三个方式的对比如下：

<table> 
 <tbody> 
  <tr> 
   <td style="border-color:#d9d9d9;width:82.5pt;"> <p style="margin-left:0;text-align:center;">方式</p> </td> 
   <td style="border-color:#d9d9d9;width:221.25pt;"> <p style="margin-left:0;text-align:center;">优势</p> </td> 
   <td style="border-color:#d9d9d9;width:321.75pt;"> <p style="margin-left:0;text-align:center;">缺点</p> </td> 
  </tr> 
  <tr> 
   <td style="border-color:#d9d9d9;width:82.5pt;"> <p style="margin-left:0;text-align:center;"><strong>点对点</strong></p> </td> 
   <td style="width:221.25pt;"> 
    <ul> 
     <li style="text-align:left;">设备端闭环，无需服务器</li> 
     <li style="text-align:left;">整体方案简单</li> 
    </ul></td> 
   <td style="width:321.75pt;"> 
    <ul> 
     <li style="text-align:left;">音视频的效果完全取决于性能最差的设备</li> 
     <li style="text-align:left;">多对多场景，会形成NxN的传输网络。每个设备端都要负责（N-1）路音频和视频的处理，整体业务性能取决于性能最差设备端能力。</li> 
    </ul> 
    <ul> 
     <li style="text-align:left;">发起呼叫时，主叫必须通过其他渠道唤醒被叫，等到处理呼叫请求。</li> 
     <li style="text-align:left;">无法进行设备状态管理，也没统一的业务管理能力。</li> 
    </ul> 
    <ul> 
     <li style="text-align:left;">灵活性差，很难扩展业务</li> 
    </ul></td> 
  </tr> 
  <tr> 
   <td style="border-color:#d9d9d9;width:82.5pt;"> <p style="margin-left:0;text-align:center;"><strong>信令中心化交换</strong></p> </td> 
   <td style="width:221.25pt;"> 
    <ul> 
     <li style="text-align:left;">由服务器统一管理设备状态</li> 
     <li style="text-align:left;">发起呼叫时，由服务器判定被叫是否能被寻呼</li> 
    </ul> 
    <ul> 
     <li style="text-align:left;">服务器功能简单，资源消耗少</li> 
    </ul></td> 
   <td style="width:321.75pt;"> 
    <ul> 
     <li style="text-align:left;">音视频的效果完全取决于性能最差的设备</li> 
     <li style="text-align:left;">多对多场景，会形成NxN的传输网络。每个设备端都要负责（N-1）路音频和视频的处理，整体业务性能取决于性能最差设备端能力。</li> 
    </ul> 
    <ul> 
     <li style="text-align:left;">灵活性差，很难扩展业务</li> 
    </ul></td> 
  </tr> 
  <tr> 
   <td style="border-color:#d9d9d9;width:82.5pt;"> <p style="margin-left:0;text-align:center;"><strong>全中心化交换</strong></p> </td> 
   <td style="width:221.25pt;"> 
    <ul> 
     <li style="text-align:left;">由服务器统一管理设备状态</li> 
     <li style="text-align:left;">发起呼叫时，由服务器判定被叫是否能被寻呼</li> 
    </ul> 
    <ul> 
     <li style="text-align:left;">服务器可以根据设备端能力，对音视频转码实现最好的端-端音质和画质。</li> 
     <li style="text-align:left;">可以在服务端灵活、方便的扩展业务链路，添加音画质优化、多媒体信息实时转储等多种业务</li> 
    </ul> 
    <ul> 
     <li style="text-align:left;">每个设备可以只处理一路传输，一路下载的多媒体数据，且无需进行混音和画面融合。</li> 
     <li style="text-align:left;">对设备端能力要求非常低。</li> 
    </ul></td> 
   <td style="width:321.75pt;"> 
    <ul> 
     <li style="text-align:left;">服务端复杂</li> 
     <li style="text-align:left;">服务端资源消耗高</li> 
    </ul></td> 
  </tr> 
 </tbody> 
</table>

根据上面的简单比对，可以看出在阿里云-IOT领域，全中心化交换方式是比较理想的RTC业务形态，因为：

*  **基于云构建RTC服务端，服务端资源可以弹性扩展，且可以方便、灵活的扩展服务端业务链路。**
 *  **IOT****场景下，设备端资源都比较有限，比较复杂的音频多路合成、视频转码、视频画质增强、视频多路融合等功能很难集成，或集成会导致设备端成本大幅增加。**

*  **随着4G、5G的铺开，云规模的不断扩大，流量价格在急剧降低，中心化交换引入的流量成本已经可以做到逐渐下降，直至低于设备端增加成本（单设备增加成本x设备数量）。**
 *  **把复杂的算法、视频动态转码等功能上移给服务端，可以让设备端极度简化，降低设备端的开发难度，节省设备端开发时间成本，特别是IOT场景下终端都比较“瘦”。上述功能上移到云，可以通过大数据、AI等方式有效的提高算法、动态转码效率，整体提升RTC业务的效率和体验。**

# **二、HaaS RTC介绍** #

HaaS RTC 是基于阿里IOT的HaaS平台搭建的实时音视频通信端云一体，软硬件一体解决方案。主要目的是提供一条完整的设备-云-设备的多媒体信息实时传递通道。主要特点是：

*  信令+承载全覆盖：实时通信的信令面和承载面均已经实现，是完整的实时通信业务包。
 *  端云一体全覆盖：端侧提供SDK方便集成，云上服务成熟可用。

*  良好的设备侧功能扩展：基于类SIP私有信令可以方便的扩展出IM消息、系统待机-唤醒等各种功能。
 *  灵活的服务侧业务链扩展：基于阿里云强大的云服务能力，可以在云上方便的集成各种音视频融合、画质优化增强、音视频实时转储、语音识别、图像识别等扩展功能。

*  多种通信场景支持：1 VS 1，1 VS N， N vs N，音视频链路（单、双向）自由配置。
 *  丰富的设备形态支持：支持在手机、PC、Linux平台嵌入式设备、AliOS Things平台物联网设备上集成。形成智能门禁、儿童手表、楼宇对讲、智能安防IPC等多种产品-业务形态。在使用AliOS Things平台还可以实现设备侧资源极致“瘦”身优化。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 4][]

其组成部分如下：

*  HaaS RTC 云服务：是通信过程中信令面服务提供者，是提供用户管理、用户状态监控、通信信令服务、业务管理等功能的服务服务端。
 *  视频云：是通信过程中承载面的服务提供者，音视频多媒体数据的汇聚、转发中心。具备音视频转码、融合、转发、转储等基本功能，同时也可以根据客户的需求在云上扩展业务链。

*  设备端：是音视频通信的客户端，其主要作用是通信数据的上传包括音视频数据的前端采集、编码、上传；通信数据的接收、解码、展示。各类具备音视频多媒体pipe line(数据采集和显示)，具备端云网络连接的IOT设备均可以作为HaaS RTC的设备端。

# **三、HaaS RTC设备端架构** #

客户集成HaaS RTC方案时主要的工作是设备端的SDK集成，一个典型的HaaS RTC设备端的架构如下：

*  底层操作系统：负责驱动硬件平台，提供操作系统层接口支持。
 *  驱动框架：提供音视频采集、编解码相关设备的驱动能、显示渲染驱动能力；

*  HAL：统一的硬件抽象层，给RTC音视频业务框架提供统一的硬件驱动访问接口，屏蔽设备驱动细节。
 *  RTC音视频框架：负责RTC的信令面协议、承载面协议的处理、音视频的实时传输接收、同时还可以扩展音频3A算法、监控RTC业务相关的系统资源情况。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 5][]

# **开发者支持** #

如需更多技术支持，可加入钉钉开发者群，或者关注微信公众号。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 6][]

更多技术与解决方案介绍，请访问HaaS官方网站[https://haas.iot.aliyun.com][https_haas.iot.aliyun.com]。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70]: /images/20221004/68dd58343da1469d93b08356729119ac.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 1]: /images/20221004/9035a5cf402b4d609f0bde9a12e3e9c2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20210715160612706.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 3]: /images/20221004/46f4252b2d13409e9652b6f60c39a8da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 4]: /images/20221004/11fe90fe06954c588790c58b4ce82fc8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 5]: /images/20221004/3b7367edf17b4fd6bef1c958c509a19b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0hhYVNUZWNo_size_16_color_FFFFFF_t_70 6]: /images/20221004/20754c6dc59d4e7fb77e956d24b8e965.png
[https_haas.iot.aliyun.com]: https://haas.iot.aliyun.com/