如何在复杂局域网网络情况下，保证视频电话功能的稳定使用？

原方案采用 webrtc + websocket + mqtt 的 nodejs 架构，websocket和 mqtt 等长链接协议在不稳定的网络架构环境内，程序超长时间运行后出现无法重连、甚至连接情况下也无法通信的情况。往往必须要人为处理才能恢复视频电话的正常使用。比如：防火墙规则调整、网络故障等等情况下。

节点 192.168.0.2—192.168.0.5 自动推送节点信息到主节点 192.168.0.1。

图1

一主多从 网关架构方案

1. 安卓 APP 集成 GRPC 协议网关、局域网内所有设备的 IP 信息都是固定的情况下，采用可以双向通信的 GRPC 协议实现设备间通信，可以有效避免 websocket 等长链接协议在超长时间运行时候的糟糕表现。

虽然 websocket 是实现聊天室的常用方案，但是在需要主动双向通信的场景下 GRPC 是更好的选择。开发方面采用 gomoble 开发和生成安卓SDK的方式，虽然性能上会有部分损失，因为 golang 的跨平台特性可以更好的开发其他平台工具来负责监控、测试和后期的运维。同时简单的语法可以更方便的完成更高的单元测试覆盖，保证后续程序可以稳定的快速更新迭代。

2. 为了满足多人视频通话的需求，主节点 需要实现 自动发现、网关信息储存、webrtc 音视频流调度等功能。

💡 自动发现可以避免每次新增、更换节点，都需要人工设置网关节点信息。

1. 当某一网关节点发起通话申请到主节点的时候，主节点收到申请将会通知所有需要通话的节点打开APP接听界面，建立webrtc连接并发生音视频流到主节点。

• 节点 192.168.0.2 拨打节点 192.168.0.3 ，同时发送拨打申请信息到主节点 192.168.0.1。

• 主节点 192.168.0.1 通知节点 192.168.0.2和192.168.0.3分别打开视频电话拨打和接听界面，并初始化 webrtc 的 PEER 连接并准备开始和主节点192.168.0.1 进行信令交互。

2. 另一端的网关节点接听发送接听申请到主节点，主节点收到申请将会把通话双方的音视频流分别发送给对方，网关节点收到对方的音视频流之后就可以打开通话界面开始通话了。

• 节点 192.168.0.3 接听，同时发送接听申请信息到主节点 192.168.0.1。

• 主节点 192.168.0.1 分别把 192.168.0.2、192.168.0.3 节点的音视频流分别转发给对方，并开始进行信令交互直到 192.168.0.2、192.168.0.3 节点收到对方音视频流并开始播放。

3. 挂断通话按接听情况可以分为未接挂断、接听挂断，未接挂断按挂断方式又可以分为手动挂断、自动挂断，如果是多人同时通话又有单次挂断、全部挂断。
   • 一对一未接挂断、接听挂断
     • 一对一通话挂断比简单，192.168.0.2-192.168.0.3 任意一个节点发送挂断申请信息到主节点192.168.0.1 ，主节点192.168.0.1通知对应需要关闭的节点关闭通话界面。
   • 自动挂断
     • 主节点192.168.0.1 生成一个定时任务，每隔3s检测一次开始通话申请时间距离现在的间隔时间，当时间间隔超过限制的等待接听时间 <40s>还没有接听通话的时候，主节点192.168.0.1通知对应需要关闭的节点关闭通话界面。
   • 多人接挂断、接听挂断、全部挂断
     • 多方通话挂断相对复杂一些，挂断的时候主节点192.168.0.1需要根据申请信息判断应该通知哪个节点,让这个节点去除哪个节点的音视频流或者这个节点应该完整的关闭通话界面。
     • 多人通话全部挂断，主节点192.168.0.1 会通知当前通话内所有节点都关闭通话界面。
       

本作品采用《CC 协议》，转载必须注明作者和本文链接