WebRTC实战-第一章-理论基础

webrtc-demo

https://webrtc.github.io/samples/src/content/peerconnection/restart-ice/
ICE server/信令server/webrtc server的区别和联系

WebRTC成为HTML5标准？SDP、STUN、TURN你想知道的都在这里！

用云服务器实现janus之web端与web通话！

基础理论

WebRTC 项目的愿景：实时通信 web 化，让 WebRTC 成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。WebRTC 必须在 HTTPS 环境下运行，你可以在https://appr.tc/、https://snapdrop.net/体验WebRTC应用，或者在
https://nashaofu.github.io/webrtc-demo/，https://webrtc.github.io/samples/查看WebRTC示例。

ICE server/信令server/webrtc server的区别和联系

• ICE server：
  分为stun/turn 两部分, 实现p2p连接建立.
  stun server: 负责p2p连接建立和媒体格式协商.
  turn server: 负责数据转发（一般情况下是p2p建立失败时, 通过turn server转发数据）.
  通常stun server与turn server为同一个server, 由coturn 实现.

• 信令server:
  辅助p2p连接建立. 在p2p连接建立之前的数据交互是通过信令server完成的.

• webrtc server:
  一般用于视频会议等场景. 主要针对多对多通信场景.

如何区分呢?
如果只需要实现1对1或者1对多通信, 我们只需要信令server及ICE server.
如果要实现多对多通信, 则需要全部(也就是需要信令server, ICE server, webrtc server).

什么是RTP/RTCP？

大多数人已经了解 TCP 和 UDP 等传输协议，当您要保证传输数据准确（例如：邮件）时，TCP 协议更好，而 UDP则更加偏向传输速度（例如：YouTube 视频）。

实时传输协议 (Real-time Transport Protocol，RTP) 又是一种用于通过 IP 网络传送音频和视频的网络协议。 RTP 广泛用于涉及流媒体的通信和娱乐系统，例如电话、视频电话会议、电视服务等。 作为一种电信标准，WebRTC 正在使用 RTP 传输实时数据。

RTP 控制协议 (RTP Control Protocol ，即RTCP) 是实时传输协议 (RTP) 的兄弟协议。 RTCP 为 RTP 会话提供额外统计和控制信息。 使用 RTCP您可以获得有关数据传输成功的数据，例如“传输过程中发生了多少数据包丢失”、“数据包延迟是多少”或“视频通话的分辨率是多少”等等。

RTP 和 RTCP 数据包的传输发生在媒体通道上，而WebRTC 负责媒体通道上的媒体传输。作为应用程序开发人员，您的责任是管理信令通道。 所以你通常不知道这些概念，而且大多数时候你不需要它们，但在开始 SDP 和 Offer-Answer 模型之前有必要先了解下 RTP/RTCP 。

什么是SDP（Session Description Protocol）？

现实生活中，如果您想让人们联系到您，您会分享您的联系信息，比如电子邮件、电话号码、Instagram 帐户、家庭住址等。 分享此类信息的最简单方法是向他们提供您的名片，而为了能够找到对方， 互联网数字名片可能包含以下信息：

• 主叫方和被叫方IP 地址
• 支持哪些媒体类型（音频、视频、屏幕共享等）
• 当前启用或禁用了哪些媒体类型（视频开/关保持/取消保持等）
• 对方都支持哪些编解码器类型

在电信领域，称这种数字名片为会话描述协议 (SDP)， SDP 包含对等点相互交谈所需的信息。WebRTC 也使用 SDP 作为通信标准来发起呼叫， SDP 只是一个可以被端点解析和操作的文本。

例如，如果用户想要保持通话，您可以通过将 SDP 作为应用程序进行操作来禁用/启用视频和音频流。 或者您的系统需要特定的视频编解码器，比方说 H.264，您可以删除除 H.264 之外的任何其他编解码器。

这就是 SDP 的强大之处，它很容易根据您的要求进行操作

下面是一个 SDP 示例，可能包含以下信息：

o=alice 2890844526 2890844526 IN IP4 10.48.1.2
//O=表示呼叫的发起者、会话ID和发起者的IP地址
t=0 0
//t= 表示会话结束时间。如果为 0，则表示会话不受时间限制
m=audio 49170 UDP/TLS/RTP/SAVPF 111 0
// m=表示media line，是session中可以存在的媒体属性。 在这种情况下，它表示音频媒体线。 此行还包含将在会话中使用的传输协议 (UDP/TLS/RTP/SAVPF)。 最后，此行包含将在会话中使用的编解码器有效载荷编号 (111, 0)
c=IN IP4 217.345.789.123
// c=表示连接信息，比如你要调用的远程设备的IP地址
a=sendrecv
a=rtpmap:111 opus/48000/2
a=rtpmap:0 PCMU/8000
//a= 表示属性线。 它定义会话和媒体行属性。 在第一行中，a=sendrcv 属性表示设备愿意发送和接收音频媒体，他还 可以有其他值，如 recvonly、sendonly 或 inactive用于不同的场景，如保持或视频关闭
// Rtpmap 属性指示音频编解码器编号的映射。 在这种情况下，111 映射到具有 48,000 bps 带宽的 Opus，而 0 映射到具有 8,000 bps 带宽的 PCMU 编解码器， 标准 SDP 中可以有更多的属性行。
m=video 51372 UDP/TLS/RTP/SAVPF 98 100
//m= 也表示媒体行，在这种情况下，它表示视频媒体线。同样，它包含传输协议和编解码器有效负载编号。
a=sendrecv
a=rtpmap:98 VP9/90000
a=rtpmap:100 H264/90000
//a= 表示属性行。 在第一行中，a=sendrcv 属性表示设备愿意发送和接收视频媒体
//rtpmap 值，98 映射到具有 90,000 bps 带宽的 VP9 视频编解码器，100 映射到具有 90,000 bps 带宽的 H.264 视频编解码器

SDP的更多属性配置可以阅读文末资料，这里不再展开。

什么是Offer-Answer模型？

到目前为止，解释了“WebRTC 如何在媒体通道中传输数据？”（RTP/RTCP）和“如何在信令通道中根据需要指定会话属性？”（SDP）。 接下来回答“应用程序应该如何相互传输会话属性 (SDP)？”。

你可能有一张华丽的名片，但如果你不把它送给任何人，它就毫无用处， 此规则也适用于 SDP。 我们需要在对等点之间交换 SDP 以发起呼叫。 Offer-Answer 模型是在 WebRTC 中用作电信标准的 SDP 交换过程，交换方式由申请时决定。 应用程序可以通过 HTTP/HTTPS 请求、Web 套接字、推送通知等方式发送它。这完全取决于应用程序。

Offer-Answer模型顾名思义，在这个模型中有一个 Offerer 和一个 Answerer。 提供者是启动信令过程的人，例如开始拨出电话或发送通话事件的人，包括保持和关闭视频开关。 回答者是回答传入提议的人， 例如接听来电或向通话中事件发送合适的数据。

Offer-Answer 模型有 4 个基本步骤；

• Offerer 创建一个 Offer SDP 并将其发送到远程节点。
• 应答者收到提议者的 SDP，并自行设置。
• Answerer 创建一个 Answer SDP 并将其发送给 offerer
• 提供者收到应答者的 SDP，并自行设置。

之后，如果一切正常，呼叫开始。

WebRTC的Offer-Answer模型交换流程

下图显示了 WebRTC 上使用 Offer-Answer 模型的 SDP（Session Description Protocol，即会话描述协议） 交换过程：

接下来一一说明这些步骤：

• Peer-1 获取用户媒体，然后从 WebRTC 创建一个 PeerConnection 对象
• 创建PeerConnection后，应用程序需要调用WebRTC的createOffer接口
• WebRTC 创建一个Offer SDP ，并且可以根据需要操作 SDP
• 应用程序应将 Offer SDP 设置回 WebRTC
• 应用程序应向 Peer-2 发送Offer SDP
• Peer-2 上的应用程序收到Offer SDP， Peer-2 应该获取用户媒体并创建 PeerConnection 对象（如果目前尚未创建）
• Peer-2 上的应用程序将Offer SDP 设置给 WebRTC
• Peer-2 上的应用程序使用 WebRTC 的 createAnswer API 生成应答 SDP
• WebRTC 创建一个应答 SDP 并将其提供给应用程序，应用程序可以根据需要操作SDP
• 应用程序应将 Answer SDP 设置给 WebRTC
• Peer-2 上的应用程序应将应答 SDP 发送给 Peer-1
• Peer-1 上的应用程序设置应答 SDP

如果一切正常，RTP 媒体流将通过 WebRTC 在媒体通道上启动。
上面可能有很多步骤，但其中大部分都是重复性任务。WebRTC 交换 offer 与网络参数之后，就会尝试直接使用对方的 IP 地址与端口进行直连，这个过程会根据双方网络情况，使用的不同的方式建立连接，后文 NAT(Network Address Translation，即网络地址转换)打洞就是介绍这部分内容。

什么是信令服务器？什么是STUN？什么是TURN？

A 与 B 在建立 WebRTC 连接过程中，需要互相知道对方的 IP 与通信端口。那么 A 与 B 要如何知道对方的 IP 与端口呢？答案就是通过信令服务器。 信令服务器的作用是作为一个中间人帮助双方在尽可能少的暴露隐私的情况下建立连接。WebRTC 并没有提供信令传递机制，你可以使用任何方式如 WebSocket 或者 XMLHttpRequest 等，来交换彼此的令牌信息。

STUN 和 TURN 服务器是两种类型的 WebRTC 信令服务器，可用于在构建实时通信应用程序时创建对等 (P2P) 连接。

什么是STUN？

STUN（NAT 会话遍历实用程序）使用 UDP 协议通过 NAT 来实现 ICE能力。 STUN 允许应用程序发现它们之间和公共互联网上的 NAT 、防火墙的存在和类型。 任何设备都可以使用它来确定 NAT 分配给它的 IP 地址和端口。

通常，STUN 客户端可以向 STUN 服务器发送消息以获取公共 IP 和端口信息，然后基于此公共 IP 和端口信息即可在客户端之间通过互联网进行点对点通信。

什么是TURN？

TURN（Traversal Using Relays around NAT）是一种协议，可协助 webRTC 应用程序穿越网络地址转换器 (NAT) 或防火墙。 TURN Server 允许客户端通过中间服务器发送和接收数据， TURN 协议是 STUN 的扩展。

在少数情况下，客户端通信端点在不同类型的 NAT 后面，或者当使用对称 NAT 时，通过中继服务器及其称为 TURN 服务器发送媒体可能更容易。

coturn

coturn 服务器完整的实现了 STUN/TURN/ICE 协议，支持 P2P 穿透防火墙。主要用于 webrtc 等点对点视频音频通话。

coturn 支持 tcp, udp, tls, dtls 连接；支持 linux bsd solaris mac os， 暂不支持 windows.
对于局域网中的webrtc是不需要coturn，因为他们自己进行视频流的传输，但通常的应用场景，在同一个局域网下概率是比较低的，因此我们需要把流推到服务器上，另外一端在从服务器把流拉下来。coturn做为turnserver做的是这一部分的工作。当然coturn也可以作为 stun服务器，这篇文章先不讲，只讲turnserver这部分的内容。

turnserver的原理是根据webrtc的协议而定的，最主要的功能就是转发webrtc上的数据流，在转发数据流中，最关键的是两样，一个是创建流端口连接，一个是匹配端口。

当webrtc的客户端配置上了ICE_SERVER 以后，客户端会去ICE_SERVER 请求一个端口用来传递数据流，这就是所谓的ice，在互换了ice以后，会选出一个通路来匹配到另一端的通路，数据在服务端中进行转发传递。

安装coturn穿透和转发服务器

安装依赖

ubuntu系统

sudo apt-get install libssl-dev
sudo apt-get install libevent-dev

centos系统

sudo yum install openssl-devel
sudo yum install libevent-devel

编译安装coturn

git clone https://github.com/coturn/coturn
cd coturn
./configure
make 
sudo make install

看到如下画面说明安装成功

默认情况下，coturn使用SQLite数据库进行用户和设置。当TurnServer第一次启动时，会自动创建（空）该数据库。

创建软链接

ln -s /usr/local/coturn/coturn/bin/turnserver /usr/bin/turnserver
ln -s /usr/local/coturn/coturn/bin/turnadmin /usr/bin/turnadmin

快速测试启动

# 命令后加&, 后台执行起来后按ctrl+c 不会停止
root@HP:/usr/local/coturn/coturn# nohup turnserver -L 0.0.0.0 -a -u coturn:coturn_123456 -v -f -r nort.gov &

# 然后查看响应的端口号3478是否存在进程
lsof -i:3478

自定义配置启动

自定义配置

listening-device=eth0						# 网卡名称
listening-port=3478							# turnserver监听UDP/TCP端口
tls-listening-port=5349					# turnserver监听TLS/DTLS端口
listening-ip=0.0.0.0							# 内网IP,但是设置内网IP会导致外部连接不到内网IP,设置0.0.0.0即可
relay-ip=10.120.92.4						# 一定是内网IP，不然relayIP会获取不到
external-ip=X.X.X.X						# 一定是公网IP
min-port=49152								# 最小端口
max-port=65535								# 最大端口
user=user:123456							# 用户名:密码
realm=X.X.X.X								#域名或者公网IP
lt-cred-mech

真实配置

注意不需要配置：external-ip
在/usr/local/coturn/coturn下新建turnserver.conf，内容如下：

# TURN server name and realm
realm=DOMAIN
server-name=turnserver

# Use fingerprint in TURN message
fingerprint

# IPs the TURN server listens to
listening-ip=0.0.0.0

# External IP-Address of the TURN server
#external-ip=122.51.240.198
#external-ip=192.168.0.44

# Main listening port
listening-port=3478

#tls-listening-port=5044

# Further ports that are open for communication
min-port=10000
max-port=20000

# Log file path
log-file=/usr/local/coturn/turnserver.log

# Enable verbose logging
verbose

# Specify the user for the TURN authentification
user=coturn:coturn_123456

# Enable long-term credential mechanism
lt-cred-mech

新建start.sh

killall -9 turnserver
rm -rf nohup.out
#nohup turnserver -L 0.0.0.0 -a -u coturn:coturn_123456 -v -f -r nort.gov &
#nohup turnserver -L 0.0.0.0 -a -u coturn:coturn_123456 -v -f -r -c turnserver.conf nort.gov &
turnserver -L 0.0.0.0 -a -v -f -r -c turnserver.conf nort.gov

测试地址，分别测试stun 和 turn

打开测试地址

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

测试stun

stun:192.168.0.23:3478
coturn
coturn_123456

检测网站
注意使用火狐游览器更好点
谷歌游览器会报错：

Note: errors from onicecandidateerror above are not neccessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4.
The server turn:X.X.X.X:3478?transport=udp returned an error with code=401:

Note: errors from onicecandidateerror above are not neccessarily fatal. For example an IPv6 DNS lookup may fail but relay candidates can still be gathered via IPv4.
The server stun:X.X.X.X:3478 returned an error with code=701:
STUN allocate request timed out.

测试 turn中继服务

此时查看日志

root@HP:/usr/local/coturn/coturn# tail -f nohup.out 

显示如下

测试网络情况

安装

apt install sysstat

查看网络情况

sudo sar -n DEV 1

20时44分38秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
20时44分39秒        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
20时44分39秒    enp1s0    164.00    243.00     11.68     41.22      0.00      0.00      0.00      0.34
20时44分39秒    wlp2s0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
20时44分39秒 br-81c00f46f7c3      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
20时44分39秒 br-cca53579becd      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
20时44分39秒   docker0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
20时44分39秒 br-589307c722b2     50.00      0.00      2.93      0.00      0.00      0.00      0.00      0.00