本文以 Web 平台为例，介绍如何在项目中，实现音视频发布流和订阅流功能。

参考示例项目

参考示例项目。

前提条件

在控制台创建 WTN 应用，在快速体验页面获取发布和订阅流的地址。

满足以下条件的计算机：

搭载 Intel 第二代酷睿处理器或更佳性能的处理器；

有可用的物理音视频采集设备，如内置摄像头和麦克风；

安装最新版本的 Chrome 浏览器，并设置为默认浏览器；

具备互联网连接。

实现功能

一次简单的音视频通话的流程图如下：

实现一次简单的音视频通话主要包含以下步骤：

1. 发布端：创建和初始化客户端对象

调用浏览器原生 getUserMedia 创建一个本地音视频流，并保存音视频轨道。

2. 发布端：创建 PeerConnection，添加 transceiver，设置 offer

3. 订阅端：创建 PeerConnection，添加 transceiver，设置 offer

4. 发布端和订阅端：与 veWTN 服务器通信，交换 offer

5. 订阅端：订阅和播放音视频流

发布订阅的双方交换 SDP 之后，peerConnection 就已经成功建联。此时订阅端 peerConnection 可在回调 ontrack 中接收到发布端的音视频流。

6. 发布端和订阅端：断开 PeerConnection

断开 PeerConnection 后，音视频流的发布和接收也将停止。

至此，我们实现了基础的音视频通话。

FAQ

1. 发布订阅的双方交换 SDP 之后，订阅端 peerConnection 无法在 ontrack 中监听到发布端的音视频流？

如遇此情况，请在实现功能时先执行步骤 5 订阅和播放音视频流，再执行步骤 4 与 veWTN 服务器通信，交换 offer。

2. 是否支持 DataChannel？如何使用？

支持。我们提供了复用媒体通道的超低延时信令通道 DataChannel，用于在多端之间实时同步自定义数据，如控制信令、鼠标操作、消息通知等。

使用方法

创建 RTCPeerConnection 后，调用相应的 API。每个 RTCPeerConnection 实例仅支持创建一个 DataChannel。

消息路由规则

消息的发送方向取决于当前 PeerConnection 的角色以及你是否在消息中指定了目标流。

指定流路由逻辑

你可以通过一个特殊格式的消息头，精确控制消息要发送给哪些流的对端。格式如下：

<WTN>{"stream_ids":["stream1","stream2"]}</WTN>your_actual_data

<WTN>...</WTN>：为固定格式标签。

{"stream_ids":[...]}：一个 JSON 对象，stream_ids 数组中包含了一个或多个目标流的 ID。

your_actual_data：你实际要发送的业务数据。

默认路由逻辑

当直接调用 channel.send(data) 发送消息时，将遵循以下默认规则：

若该连接上有发布流，则该消息将被广播给所有订阅了这些流的接收端。

若该连接上没有发布流（即纯订阅端），则该消息将被发送给所有它所订阅的流的发布端。

场景示例

场景1：一对多广播（1 位发布者 vs. 多位订阅者)

假设，A 发布流，B、C、D 订阅 A。

发送方	默认接收方	关联规则与逻辑说明
A	B, C, D	A 是发布者，其消息会广播给所有订阅者（B、C、D）。
B	A	B/C/D是纯订阅者，其消息会定向发送给它所订阅的发布者（A）。
C	A
D	A

场景2：1 V 1 互动（互为发布与订阅者）

A发布 stream_A 并订阅 stream_B；B发布 stream_B 并订阅 stream_A。

发送方	默认接收方	关联规则与逻辑说明
A	B	A是发布者，其消息会发送给它的订阅者（B）。
B	A	B也是发布者，其消息会发送给它的订阅者（A）。

场景3：复杂的多对多协作

A 发布流，同时被 C 和 D 订阅。

B 发布流，同时被 A 和 D 订阅。

因此，A 是发布者也是订阅者，B 是发布者，C 和 D 是纯订阅者

发送方	默认接收方	关联规则与逻辑说明
A	C, D	A 是发布者，其消息会广播给所有订阅了它的用户（C 和 D）。
B	A, D	B 是发布者，其消息会广播给所有订阅了它的用户（A 和 D）。
C	A	C 是纯订阅者（只订阅了 A），其消息会定向发送给它所订阅的发布者（A）。
D	A, B	D 是纯订阅者（同时订阅了 A 和 B），其消息会定向发送给它所订阅的所有发布者（A 和 B）。

WebRTC 传输网络