导读｜随着互联网出海的热潮袭来，语聊社交出海再度掀起新一轮风口，国内外基于语音聊天室的社交 App 如雨后春笋般涌现出来。然而随着国内同质化竞争加剧，大量国内团队选择出海分一杯羹。那么海外语聊社交场景有什么特点？其实现方案又与国内有何不同？读完本文，你将能够理解并掌握基于腾讯云实时音视频搭建语聊房的基本要素，以及海外语聊方案的具体实现和优化思路。什么是语聊社交？ ● 主要特点语聊社交是指以纯音频为载体的线上互动社交行为，其中以语聊房为代表，房间内通常设有数个麦位，主播和连麦听众在麦上聊天，其他听众可以进入房间收听。不同类型的房间麦位数量和可容纳最大听众数量不同。腾讯云实时音视频 TRTC 支持最多50人同时上麦聊天，上下麦平滑切换，语聊时延低于300ms，支持变声、气氛音效、混响等多种音频效果，让语聊体验更加丰富。结合即时通信 IM，支持公聊、私聊、群聊、点赞、送礼等多种消息互动形式，打造良好的聊天互动体验。语聊社交 App 示例 ● 场景玩法1）1V1语聊房1V1语聊房常见的应用场景有单聊、陪聊、语音匹配交友等，大部分社交类App都上线了1V1语聊功能，通常分为免费和付费两种模式。2）多人语聊房多人语聊房延伸出的玩法非常多，其中每种玩法都有所差别。除了多人纯语聊，还有跟其他娱乐形式结合的玩法。比如在线会议、游戏开黑、赛事直播、一起看电影等。3）电台语聊房在电台语聊房场景中，通常会有主播单人直播或主持人和几名陪聊嘉宾，同时播放背景音乐和音效，麦下观众可以赠送礼物，上麦参与语音互动。 4）KTV 语聊房在KTV语聊房场景中，大家可以点歌、接唱、合唱等，主要分为排麦独唱和实时合唱两种模式。 排麦独唱为一个人主唱，其他连麦用户排队等候轮唱。 实时合唱为多个人同时合唱，连麦用户可以随时申请加入合唱。如何搭建语聊社交应用？通常一个完整的语聊社交应用，根据功能的完整度，可以分为四个层级：基础组件、功能层、应用层、业务层。整体架构如下所示，接下来会逐个讲解各层级的内容，以对搭建语聊房的基本要素有个比较完整的认知。语聊社交技术架构 ● 基础组件：提供最基础的能力，比如音频互动、文字交流、回放存储等，该组件主要以SDK或者某一单独的服务呈现，比如实时音视频SDK、即时通信IM SDK、直播/点播服务、审核服务等。 ● 功能层：基础组件中能力的应用，比如弹幕，就是使用到即时通信IM SDK中的文字交流的能力；还有麦位移动，是指麦位列表中的某人的麦位进行了变更，也是借助了即时通信IM的信令能力，将某人麦位变化的信息下发到房间内。 ● 业务层：功能模块的聚合，比如创建房间、房间列表、进/退房就是房间管理的聚合；上/下麦、麦位移动、麦位禁言、锁麦/解锁麦就是麦位管理的聚合。 ● 应用层：最终呈现给用户的业务形态，比如1V1语聊、多人语聊、语音电台等都是业务层根据一定玩法形态展现给用户的。在整个语聊技术架构实现中，难度最大的是基础组件的实现。如果完全进行自研的话，开发成本高而且周期较长。比如开发实时音视频组件，就需要具备专业的音视频底层技术开发能力，还需要处理一系列的机型适配、漏回音、无声、节点部署、网络互通等复杂问题。为此我们可以考虑使用云上提供的基础组件，站在巨人的肩膀上，能够有效降低开发成本，实现快速上线。如何基于腾讯云实现语聊社交？腾讯云提供了丰富的基础组件，能满足实现语聊房所需的基础组件。接下来将基于腾讯云提供的基础组件，对语聊房架构实现进行详细的讲解，并从核心业务模块中的房间管理、麦位管理、音视频流管理，录制与审核，贯穿核心功能进行分析。1）房间管理语聊社交主要是在一个个房间内进行语音互动的，创建房间的用户是为主播，其他进入房间的用户为观众。房间管理主要负责对一个个房间进行管理，主要功能包括对房间的创建、销毁、加入、退出。 ● 技术架构在房间管理的实现中，主要有房间列表、房间创建/销毁/进入/退出的功能。功能看似比较简单，是否由业务侧自己完全实现就可以了呢？答案是否定的，因为房间内使用的其他功能，比如消息收发、信令收发、音频流收发，都使用到了即时通信IM与实时音视频TRTC的能力。既然IM和TRTC都有房间管理，是否直接基于这两个基础组件就能快速实现呢？答案也是否定的，因为房间中的业务侧信息，比如链路情况、礼物列表，主播头像等信息和房间列表等功能，IM和TRTC不直接提供此类功能。所以在整个房间管理中，必须由业务侧房间模块（管理服务/列表服务）、即时通信IM模块（SDK/后台）、TRTC模块（SDK/后台）三大模块进行组合实现。具体的架构流程如下图所示：房间管理模块架构 ● 具体实现在房间管理的实现中会区分不同的角色，主要分为房主、听众两种角色。房间最高权限的拥有者，可以创建或者销毁房间● 角色必须为主播
● 创建或者销毁业务房间/IM群组/TRTC房间房间的参与者，也可以上麦变成主播● 角色可以为观众/主播
● 进退房间不同角色的具体实现流程如下：房主房主房间管理流程 1.
通过业务侧接口创建相应的房间； 2.
创建IM群组； 3.
进入业务房间/IM群组/TRTC房间，与其他人进行互动； 4.
退出IM群组/TRTC房间/业务房间； 5.
销毁IM群组/业务房间。听众听众房间管理流程 1.
获取房间列表； 2.
进入业务房间/IM群组/TRTC房间，与其他人进行互动； 3.
退出IM群组/TRTC房间/业务房间。2）麦位管理语聊房内的麦位一般都是有序且有限的，比如听众上麦一般需要经得房主的同意后有序上麦，并且房间内的麦位数量通常在 5-10个之间。麦位管理主要负责根据业务场景定义房间内的麦位数量，以及当前房间所有麦位的状态管理。麦位管理主要包含上/下麦、换麦、锁麦位、邀请上麦、麦位禁言等功能。 ● 技术架构在麦位管理的实现中，主要有抱人上麦、踢人下麦、麦位禁言、麦位移动、麦位静音等功能。首先需要业务后台维护一套用户麦位列表状态的信息，即为业务麦位服务，而在用户上麦/下麦的时候，则需要用到即时通信IM的能力，将用户上下麦与房主同意的相关信令下发到客户端。然后在用户进行语音互动交流的时候，则需要用到实时音视频TRTC的能力，调用TRTC SDK接口开启语音推拉流。所以在整个麦位管理中，必须是由业务侧麦位模块（管理服务/列表服务）、即时通信IM模块（SDK/后台）、TRTC 模块（SDK/后台）三大模块进行组合实现的。然而正因为用户上麦/下麦所用到的模块比较多，任意模块与其他模块出现状态不统一的时候，都会出现“幽灵麦”现象，关于“幽灵麦”后续章节会展开详细介绍。因此每个模块都需要按照一定的流程正确进行，具体的架构流程如下图所示：麦位管理模块架构 ● 具体实现在麦位管理的实现中会区分不同的角色，主要分为房主、听众两种角色。麦位最高权限者，负责所有麦位的管理，房主退房后会自动解散所有麦位● 角色必须为主播
● 进房自动上麦
● 同意/拒绝上麦申请
● 抱人上/下麦
● 管理麦位的静音/解禁
● 管理麦位的封禁/解禁房间内麦位参与者，可以上下麦互动● 角色可以为观众/主播
● 申请上/下麦不同角色的具体实现流程如下：房主房主麦位管理流程 1.
房主创建并加入房间； 2.
根据房间属性获取到麦位列表，并主动上麦； 3.
听众上麦有两种方式，一种是听众主动申请上麦，房主同意，另外一种是房主邀请听众上麦，听众同意； 4.
听众上麦后，与麦位上的其他人进行互动； 5.
听众下麦有两种方式，一种是听众主动下麦，另外一种是房主将听众抱下麦； 6.
房主退出并销毁房间； 听众听众麦位管理流程 1.
听众进入房间； 2.
听众获取麦位列表； 3.
听众申请上麦，房主同意后，将上麦与麦上其他主播互动； 4.
听众退出房间；3）音频流管理音频流管理是将房间内TRTC SDK采集到的房主/主播的声音经过网络传输后，再拉流并播放给听众。其中拉流有两种方案：TRTC房间订阅拉流、转推CDN直播拉流。 ● 技术架构音频流管理模块架构 1）
TRTC房间订阅拉流：通常小规模语聊房场景可以选择纯RTC流接入方案，技术复杂度更低，亦可体验到更好的实时互动特性； 2）
转推CDN直播拉流：由于TRTC采用UDP协议进行音视频数据的传输，而标准直播CDN则采用RTMP\HLS\FLV等协议进行数据传输，所以需要将TRTC的音视频数据旁路到直播CDN中，才能在让观众通过直播CDN拉流观看。 ● 具体实现RTC流订阅模式纯RTC流接入方案易用性强，且具备最佳的实时互动性。如下图所示，以麦上用户和麦下观众两个角色展示了一种最经典的实时互动语聊房的推拉流方案架构。RTC推拉流方案架构针对房间内的实时流订阅，TRTC共有两种订阅模式可供选择：自动订阅、手动订阅。自动订阅：默认模式，用户在进入房间后会立刻接收到该房间中的音频流，音频会自动播放；手动订阅：用户进入房间后，需要手动调用muteRemoteAudio启动音频的播放。在绝大多数场景下，用户进入房间后都会订阅房间中所有主播的音频流，因此TRTC默认采用了自动订阅模式，以求得最佳的“秒开体验”。 而手动订阅模式则具备更好的灵活性和可定制性，用户可以选择性地订阅音频流。CDN流拉取方案CDN直播观看，也叫 “CDN 旁路直播”。TRTC的低延时观看能力，单房间支持的最大人数上限为10万人。CDN观看虽然延迟要高一些，但支持10万人以上的并发观看，且CDN的计费价格相对便宜。转推CDN拉流示例拉流方案对比下面将以四种拉流方案为例，从技术难度、费用成本、观看效果、人数限制、应用场景等维度进行对比分析：互动游戏房等KTV语聊房等强自定义布局规模并发观看4）录制与审核管理由于国内外相关监管政策的要求，有对语聊房音频内容进行录制存储的需求。录制与审核的相关介绍如下： ● 技术架构在录制与审核管理中，主要有录制、审核、用户封禁等功能。首先需要业务后台维护录制相关的服务，用来管理主播的回看与调用TRTC后台或者CDN开启录制服务，然后在TRTC后台/CDN收到业务侧的服务后，将拉到的音视频流数据保持在数据存储中心，一般保存在COS中；另外业务后台也是需要维护审核的服务，调用开启和接收天御的审核服务与告警，如果审核确认是违规的内容的话，则还需用到即时通信IM的能力，通过信令通知违规的用户下麦。具体的架构流程如下图所示：录制与审核方案架构 ● 具体实现云端录制方案云端录制是通过TRTC的“哑终端”的方式进到TRTC的房间内拉流，能对房间内的单流或者合流进行录制，整体的方案可以参考官网文档，业务侧通过调用相关的云端录制接口，进行录制。CDN录制方案CDN录制是通过TRTC后台的混流转码接口/TRTC SDK混流转推接口，混流转码转推到腾讯云直播/第三方CDN，并通过腾讯云直播/第三方CDN的相关录制服务，进行录制。天御审核方案TRTC联合T-Sec天御，提供了实时的音视频内容识别与告警服务，客户在使用实时音视频服务时，支持手动或全局自动发起策略进行音视频内容的识别和告警：手动自定义审核：客户只需要调用天御音视频流接口即可实时检测音视频流中是否出现违规内容，音视频安全审核服务会通过回调把违规信息发送给客户指定的回调 URL；全局自动审核：客户可指定审核策略和审核流类型，TRTC云端自动帮忙完成应用下所有房间内的音视频内容审核，并通过回调把违规信息发送给客户指定的回调 URL，无需手动发起审核。封禁方案在内容审核服务监测发现有违规内容的时候，通过回调给业务审核的服务，业务审核服务通过机器/人工再审核的方式的确定是否是违规内容，如果确认是违规的内容，则通过即时通信IM后台给违规的主播发送封禁消息，主播在收到封禁消息时，停止音视频流上行。海外语聊技术特性与解决方案在整个语聊技术架构中，核心是实时音视频通信能力。平稳且流畅的用户体验，是出海语聊应用的制胜法宝。然而，海外纷繁复杂的基础设施和网络条件对于实时音视频的挑战是巨大的。针对海外语聊技术特性，我们总结了几点常见问题及其解决方案。 ● 海外复杂网络应对海外部分国家网络基础设施薄弱，网络整体呈现带宽低、延迟高、资费贵等特性。对于海外复杂的网络环境，腾讯云音视频在全球网络部署、QoS&QoE等方面均有针对性优化措施。腾讯云音视频在全球70多个国家和地区部署了超过2800个CDN加速节点，全网带宽资源储备高达200T+。音视频QoS优化针对海外入网环境，通过云端智能调控，确保极端网络环境下引擎策略也可以配置化。云端智能流控引擎可以快速调整音频帧长、FEC比例、JitterBuffer大小等，确保适应极端弱网环境，如限带宽、高丢包、突发抖动等场景。甚至针对部分地区UDP封禁的情况，可以降级至TCP实现互联互通。腾讯云全球网络部署 ● 音频带宽优化策略 1）
音频质量动态配置实时音视频TRTC提供了三种精心校调好的音质模式：人声模式、默认模式、音乐模式，用来满足各种垂直场景下对音质的差异化追求。不同的音质模式侧重点各不相同，实际场景中可以根据偏好（保音质/保流畅）选择配置。另外，TRTC还支持在通话过程中动态调整音频质量，以便让用户在不同网络环境下均能拥有良好的听感体验。采样率：16k；单声道；编码码率：16kbps具备最强的网络抗性，在弱网环境下流畅度最佳采样率：48k；单声道；编码码率：50kbps对音乐的还原度比人声模式要好，同时传输数据量比音乐模式要低很多采样率：48k；全频带立体声；编码码率：128kbps音频传输的数据量很大，适合需要高保真传输音乐的场景2）房间内音频混流在语聊房场景中，一般都有8个聊天主播，按每人50kpbs音频码率计算的话，观众收听则需要400kpbs的下行带宽的要求，往往在海外网络比较差的环境中，几乎无法正常收听。另外400kpbs的码率对部分低端的手机性能挑战也是很大，为此我们也通过音频混流来对下行带宽进行了优化。基于能量竞争选路的房间内音频混流技术，在确保最终的产品能力和不混流对齐的情况下，能够大幅降低用户下行带宽，提升弱网抗性。基于能量竞争选路的音频混流方案音频混流回推：选择在房间内把上行音频混在一起之后，再推回房间，然后用户拉流的时候只需拉一路，就能收到8个人的声音，这可以直接把下行带宽的占用从400k降到50k，对用户下行网络有极大的改善。音频混流下发单流音量：对于拉单流的用户，能根据某个流的音量变化进行音浪展示，而通过混流就很难分辨出来了。为此我们通过在云端混流时将发言人的userid和音量信息下发到SEI中，这样在拉流时通过解析SEI信息，就能展示单流音量了。 ● 幽灵麦预防与检测幽灵麦，又称炸麦或黑麦，是指不在麦上的用户能说话，并且其他用户能听到其说话的声音。在海外用户经常会遇到，如果没有合适的手段制止的话，会对其他用户体验造成很大的影响。幽灵麦出现的根本原因是业务的麦位状态跟TRTC房间的推拉流状态不一致，可能存在以下几种情况： ● 听众下麦麦位列表更新了，但因IM群组属性未更新，所以未及时调用TRTC切换角色为观众和关闭麦克风，从而导致处于麦下却还能发言； ● 听众下麦麦位列表更新了，但调用了TRTC切换角色接口，因网络原因失败了，从而导致处于麦下却还能发言； ● APP被暴力破解，从而导致usersig被黑客截获，从而能进到TRTC房间自由发言。应对策略可以分为几个步骤：权限预防、实时检测、踢出幽灵麦用户。1）权限预防通过开启TRTC的高级权限控制可以更加细粒度地控制用户进房及上麦权限，从而防止幽灵麦现象的发生。开启高级权限控制后，TRTC的后台服务系统不仅会校验UserSig这一个“进房票据”，还会校验一个叫做PrivateMapKey的“权限票据”，权限票据中包含了一个加密后的roomId和一个加密后的“权限位列表”。步骤一：在TRTC控制台中开启高级权限控制当某一个SDKAppid开启高级权限控制后，使用该SDKAppId的所有用户都需要在TRTCParams中传入 privateMapKey 参数才能成功进房。步骤二：在服务端集成计算PrivateMapKey由于客户端非常容易被逆向破解，从而导致权限控制失效，因此PrivateMapKey只适合在服务端计算再返回给您的App，绝不能在您的App端直接计算。步骤三：服务端下发鉴权参数给客户端如下图所示，当您的服务器计算好PrivateMapKey之后，就可以在需要的时候下发给您的客户端，SDK会在进房、上麦两个时刻校验PrivateMapKey，你可以在此时控制用户权限。鉴权流程示例图2）实时检测幽灵麦用户通过检测幽灵麦，可以主动识别并处理幽灵麦。这里推荐使用纯服务端方案：实时主播列表检测幽灵麦。方案原理：语聊房场景下用户角色分为主播和观众，只有主播角色能够上行本地音频，因此可以通过对比业务麦位列表和 TRTC 角色列表来检测幽灵麦。TRTC 提供了服务端的房间与媒体事件回调，您可通过监听“切换角色”事件来维护一个当前房间的实时主播列表。然后将 TRTC 实时主播列表和业务全量麦位列表进行比对，即可轻松检测识别出幽灵麦，然后执行踢出房间或禁言等操作。步骤一：实时音视频 TRTC 控制台支持自助配置回调信息，配置完成后即可接收事件回调通知。详细操作指引请参见 回调配置。步骤二：接收并解析回调事件包体，关注 105-切换角色事件，统计当前房间实时在线的主播角色用户列表。详情参见 事件回调。3）踢出幽灵麦用户基本原理：通过TRTC后台的移除用户接口 RemoveUser，强行将幽灵麦用户从房间内踢出，并配合高级权限控制，从而确保该用户无法再次进入房间。 ● 安全合规腾讯云实时音视频遵从不同国家和行业的合规性要求，除了保证所提供服务的安全性、合规性、可用性、保密性和隐私性之外，还可以满足企业及其客户的多项合规监管需求。腾讯云实时音视频还拥有一套独立完整的国际站点，海外环境部署与国内完全隔离，数据不会回传国内，符合海外法律法规。此外，腾讯云也通过了70项全球权威认证，例如ISO 27017/27018/27701/29151、CSA STAR、NIST CSF等。腾讯云音视频安全合规认证总结与展望本文主要介绍了语聊社交的常见场景与具体的实现方案，并且针对出海可能遇到的挑战及其解决方案进行详细分享，相信随着国内越来越多的公司出海，还会继续遇到更多新的挑战，欢迎大家到评论区留言，一起讨论。