基于 <live-pusher> 和 <live-player> 所构建的双人视频通话功能。
技术指标
通讯延迟：300ms - 800ms
底层协议：基于 UDP 协议构建，并遵循 RTMP 标准对音视频数据进行切分和封装，支持丢包恢复和网络自适应。
安全加密：每次连接都独立启用一对全新的非对称加密密钥，整个通讯过程无法监听和篡改。
支持录制：如果需要可以在云端进行录制，适用于在线客服、金融开户等商用音视频解决方案，支持私有化部署。
内部原理
通讯的双方 各自创建一个 RTC 模式的 <live-pusher> 和 <live-player> ， 然后URL 给对方。
流程
step1：首先A 跟业务服务器沟通，获取 push-url-A 和低延时的 play-url-A，服务器分配 URL 的方法参考 DOC。
step2：A 创建一个 RTC 模式的 标签，指定 url 为 step1 中获得的 push-url-A，并通过 bindstatechange 属性绑定一个 javascript 函数（比如叫 onPushEvent）。
step3：A 这边需要一些时间启动推流，推流开始以后， <live-pusher>会通过 onPushEvent 的 PUSH_EVT_PUSH_BEGIN（1002）事件通知给 A， 此时 A 可以向 B 发起通话请求，请求中可以携带 play-url-A。
step4：B 需要等待 UI 界面上的确认，如果 B 确认接通，接下来要做的就是创建一个 RTC 模式的 <live-player> ，并指定 src 为 play-url-A。
step5：B 此时还要跟业务服务器沟通，获取 push-url-B 和低延时的 play-url-B，并创建一个 RTC 模式的 <live-pusher> 标签，指定 url 为 push-url-B，并通过 bindstatechange 属性绑定一个 javascript 函数（比如叫 onPushEvent）。
step6：B 此时需要一些时间启动推流，推流开始以后， <live-pusher> 会通过 onPushEvent 的 PUSH_EVT_PUSH_BEGIN（1002）事件通知给 B，之后 B 可以向 A 响应通话请求，请求中可以携带 play-url-B。
step7: A 此时要做的就是创建一个 RTC 模式的<live-player> ，并指定 src 为 play-url-B。
在真实的场景中，我们需要面对的业务逻辑远比简单的把 A 和 B 连接起来要复杂。
房间管理
以金融开户和保险定损为例，如果 A 端使用的是小程序，那么真正的 B 端一般情况下会是企业的客服职员（通常都是一个人），所以这里就牵扯到要给用户分配客服的逻辑。同时，如果目前所有的客服都是忙碌的，那就需要有排队等待的逻辑。
所以， 真实场景下的逻辑是这样的 ： 客服 MM 在进入工作岗位后即创建好一个属于自己的“房间”，这个房间有三种状态：BUSY(占线)、IDLE(空闲) 以及 CLOSE(关闭)。处于 BUSY 状态的房间表示对应的客服正在跟用户进行沟通， IDLE 表示可以分配给新进来的呼叫，CLOSE 则表示客服 MM 已经下班了。
消息系统
在 A 和 B 之间搭建 IM 消息系统 也是必不可少的，一方面，如果 A 和 B 中某一方网络发生异常，那么文本消息可以用极低的带宽维持最基本的消息通讯；另一方面，消息系统对于事件的传递要比音视频通道更加可靠。
现代实时音视频系统一般都有数据通道和信令通道两个传输通道，这样设计的原因是音视频通道并不适合用于传输信令，比如 B 端的 通知音视频数据没有了，可能原因是 A 已经挂断，但也有可能是 A 的网络出现了长时间的波动。而基于消息系统的“挂断事件”则不需要考虑这种不确定性问题。
