WebRTC信令、连接与排错 · WebRTC

返回分篇目录

WebRTC

WebRTC

WebRTC 实时通讯传输音频的场景
WebRTC优先使用UDP传输；ICE还需考虑TCP和TURN中继等受限网络路径，不能把RTCPeerConnection等同于单一UDP通道。

实现目标以及计划

• 音视频即时通讯目标
  跨平台、 高质量、高清晰度，高流畅度
• 第一阶段计划
  实现一对一音视频通讯，不考虑清晰度、流畅度、不跨平台
• 第二阶段计划
  实现多人音视频通讯，不考虑清晰度、流畅度、不跨平台
• 第三阶段计划
  优化跨平台、流畅度、清晰度

需要准备

• WebRTC与WebSocket 技术基础支撑
• 反向代理服务(Nginx..)；浏览器采集媒体需要安全上下文，生产通常使用HTTPS，本机可信来源有例外。
• 信令服务
• STUN地址发现、TURN中继服务，以及客户端的ICE候选收集和连通检查；ICE不是另一种待部署的穿透服务器。

实现思路（个人）

• 实现唤起界面
  1. A-->B 发起请求音视频通讯通过websocket 推送消息
  2. 至B 同意之后，A、B双方唤起音视频界面
  3. 双方建立RTC（音视频）通讯
• 信令服务P2P结合WebRTC通讯
• NAT穿透服务（STUN、TURN、ICE）
• 多人通讯

技术难点

• P2P内网穿透
  • ICE介绍
  • STUN-golang-github
  • DTLS
  • VOIP
  • DataChannel
  • SCTP
  • turn-C/C++-github
• QoS/QoE（高质量、高流畅度）
  • QoS需要结合网络设备和系统策略，应用拥塞控制本身不能保证独占带宽。
  • 其他下载占用带宽时，评估码率自适应、丢包恢复和延迟；没有网络侧策略不能承诺IMClient(APP/PC)始终带宽优先。
• 丢包
  • 在实现音视频通讯情况下
  • 丢包以及重新补包

参考文章

• GO-turn
• W3c
• go-github-test
• go-paclage
• go-github-pion-package
• go+CGO+C/C++-github
• go-use-rtc
• 搭建测试-test
• 微信实时视频聊天技术的演进
• 必备基础
• WebRT 入门
• 网易云信
• WebRTC client
• 学习网址
• ..

STUN、TURN、ICE

以下锥形/对称分类是历史简化模型；实际连通性还取决于映射、过滤行为与防火墙，不能仅按一个NAT标签保证UDP穿透成功。

• Full Cone NAT： 完全锥形NAT，所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号，并且任何一个外网主机都可以通过这个映射的外网IP和端口号向这台内网主机发送包。
• Restricted Cone NAT： 限制锥形NAT，它也是所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号。与完全锥形不同的是，外网主机只能够向先前已经向它发送过数据包的内网主机发送包。
• Port Restricted Cone NAT： 端口限制锥形NAT，与限制锥形NAT很相似，只不过它包括端口号。也就是说，一台IP地址X和端口P的外网主机想给内网主机发送包，必须是这台内网主机先前已经给这个IP地址X和端口P发送过数据包。
• Symmetric NAT： 对称NAT，所有从同一个内网IP和端口号发送到一个特定的目的IP和端口号的请求，都会被映射到同一个IP和端口号。如果同一台主机使用相同的源地址和端口号发送包，但是发往不同的目的地，NAT将会使用不同的映射。此外，只有收到数据的外网主机才可以反过来向内网主机发送包

进步了解

• STUN（Session Traversal Utilities for NAT）帮助客户端获得服务器看到的映射地址，也用于ICE连通检查；它本身不是完整的NAT穿透方案，不保证识别NAT类型或建立直连。原记录引用的RFC5389已由RFC8489取代，受限网络还可能需要TURN中继。
• TURN
  • 搭建 TURN服务器
  • 测试地址
• ICE

补充实践：WebRTC

来源：jekyall_blog；原记录日期：未标注。以下保留来源案例的环境和版本范围。

WebRTC

概述

• 官网:https://webrtc.org/
  • https://webrtc.github.io/samples/
  • APIs介绍:https://webrtc.org/
• WebRTC 协议介绍

https://developer.mozilla.org/zh-CN/docs/Web/API/WebRTC_API/Protocols

将呼叫邀请与连接协商分开

旧计划中的“B同意”属于产品呼叫状态，随后仍要完成会话描述交换、候选检查和安全传输建立。拒绝邀请、用户撤销、连接失败与通话结束应是不同状态；重复或延迟到达的信令应关联呼叫ID，避免结束后的旧消息重新唤起界面。图示是对历史计划的机制整理，未建立真实音视频连接。

查看图表代码

多人方案的路径差异

全网状适合说明端点直接交互，但每增加一人都会增加多条连接和上传副本。SFU集中接收并按订阅转发，MCU还会进行混合处理；二者都需要服务端容量和故障设计。TURN只是中继某条传输路径，不能因为所有流量经过同一TURN主机就把它称作SFU或MCU。

查看图表代码