Webrtc的通话原理

本文记录了在学习Webrtc时的原理解析和思路，有错误感谢提出

Webrtc作用：简单来说就是建立一个互联网浏览器间的实时通信的平台；

从问题展开学习思路：当两个不同网络环境的（具备摄像头/麦克风多媒体设备的）浏览器，要实现点对点的实时音视频对话，难点在哪里？

问题一：假设A和B为要进行通信，如果此时A端采用的是VP8做编码，并将数据发送给B端，由于B端只有h264和VP9所以B端是无法进行解码的；
解决方法是要提前进行媒体协商，要知道对方支持的媒体格式，然后使用双方都支持的格式进行通信；

如何实现媒体协商？
利用SDP协议，SDP协议用于描述会话的信息，双方在通信前会交换SDP信息，知道对方支持的媒体格式，这样就完成了媒体协商；

问题二：解决媒体格式问题还需要考虑网络是否可达的问题？
理想情况是：每个浏览器的电脑都有私有公网IP，可以直接进行点对点连接；
实际情况是：我们的电脑和电脑之间都是在某个局域网中，那如果A端和B端不在同一局域网是无法直接通过自己的局域网IP进行连接通信的，这就需要公网IP，公网IP就是每个路由器也就是一个局域网分配的公网IP，但是局域网内的电脑无法直接查看自己的外网IP，需要NAT（网络地址转换），也就是根据自己所在的局域网的公网IP获得自己的公网IP；

如何获取到外网端口映射？
使用STUN网络协议，允许位于NAT后的客户端(也就是局域网内的电脑)找出自己的公网地址，并将局域网的IP与外网IP+端口进行绑定；

STUN是如何工作的？
客户端向STUN服务器请求获取外网IP+端口的映射，两端再使用获取到的IP+端口进行尝试连接；

如果此时两边使用公网ip+端口还是连接不上那咋办？
那就需要一个媒体服务器进行转发，就是TURN服务器；
TURN是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果终端在网络地址转换之后，还是有可能无法和对端完成（p2p）直接通信，这时就需要公网的服务器作为一个中继，对来往的数据进行转发；这个转发的协议就被定义为TURN；
中继服务器的缺点：消耗带宽，理论上是p2p的两倍；

如何进行媒体协商，如何完成媒体信息和网络信息的交换？
使用信令服务器；
信令服务器不只会传输媒体协商信息和网络信息，还需要有一个房间管理的概念；
房间管理：比如，A和B在通过信令服务器交换信息，C和D也在交换，这时不能将A的信息发送给C和
D，所以有了将A和B放入一个房间的概念；

深入理解Webrtc时序图

①假设A为发起者，B为接受者；首先A和B都会先连接信令服务器；两边都会先创建一个PeerConnection，并加入本地媒体流(视频+音频)；
②CreateOffer会产生一个回调，获取到sdp，就会知道自己支持哪些编解码格式；SetLocalDescription将sdp信息设置到PeerConnection里；
③将SDP发送到信令服务器，信令服务器在转发到B端，B端调用setRemoteDescription来设置别人的sdp，并CreateAnswer & SetLocalDescription将sdp设置到自己的PeerConnection里去；
④B端设置完后将回复的sdp信息通过信令服务器发送给A端，A端同理通过setRemoteDescription设置sdp来达到两端支持相同的编解码格式，此时完成媒体协商；
⑤此时开始网络协商，A端调用ICE Request向STUN服务器请求获取公网信息，onIceCandidate是PeerConnection提前绑定好的回调，一旦调用ICE Request时PeerConnection就会获得公网信息，拿到公网信息之后通过信令服务器发送给B端；
⑥B端收到A的网络信息就会调用AddIceCandidate进行添加自己的candidate组里，B端同样会向STUN服务器请求网络信息，并在次通过信令服务器进行转发；A端收到同理将B的网络信息添加到自己的Candidate组；
⑦最后，Webrtc内部就会使：A和B的Candidate组内的公网IP+端口会相互尝试连接，如果成功连接就代表打洞成功，也就是p2p了，可以开始不经过服务器了，开始点对点传输；如果最后还是打洞不成功，就不能点对点了，就需要TURN中继服务器(图里没有)进行传输了；
⑧onAddStream获取到对方的媒体流；