webRTC是P2P点对点通信（不需要依赖服务器，但也不是完全不依赖，还需要信令服务器

实现原理

要实现两个客户端的实时音视频通信，并且这两个客户端可能处于不同网络环境，使用不同的设备，要解决以下问题：

1. 如何发现对方（信令服务器）

在P2P通信过程中，双方需要交换一些元数据，比如媒体信息，网络数据等信息，我们通常称这一过程为“信令”。对应的服务器即“信令服务器”（也有人称为“房间服务器”，因为它不仅可以交换彼此的媒体信息和网络信息，同样也可管理房间信息）（之后会用webSocket来实现信令服务器）比如: 1)通知彼此 who 加入了房间; 2) who 离开了房间 3)告诉第三方房间人数是否已满是否可以加入房间。为了避免出现冗余，并最大限度地提高与已有技术的兼容性，WebRTC 标准并没有规定信令方法和协议。在本课程中会使用websocket来搭建一个信令服务器

2.不同的音视频编解码能力如何沟通?（SDP）

不同浏览器对于音视频的编解码能力是不同的。比如: 以日常生活中的例子来讲，小李会讲汉语和英语，而小王会讲汉语和法语。为了保证双方都可以正确的理解对方的意思，最简单的办法即取他们都会的语言，也就是汉语来沟通。在WebRTC中：有一个专门的协议，称为 Session Description Protocol(SDP)，可以用于描述上述这类信息。因此：参与音视频通讯的双方想要了解对方支持的媒体格式，必须要交换 SDP 信息。而交换 SDP 的过程，通常称之为媒体协商。

3.如何联系上对方?（利用ICE 机制找到能联系上对方的IP地址）

其实就是网络协商的过程，即参与音视频实时通信的双方要了解彼此的网络情况，这样才有可能找到一条相互通讯的链路。理想的网络情况是每个客户端都有自己的私有公网IP 地址，这样的话就可以直接进行点对点连接。实际上呢，出于网络安全和其他原因的考虑，大多数客户端之间都是在某个局域网内，需要网络地址转换 (NAT)。在 WebRTC 中我们使用ICE 机制建立网络连接。ICE 协议通过一系列的技术(如 STUN、TURN 服务器)帮助通信双方发现和协商可用的公共网络地址，从而实现 NAT 穿越。

ICE的工作原理如下:

首先，通信双方收集本地网络地址(包括私有地址和公共地址)以及通过 STUN 和 TURN 服务器获取的候选地址。
接下来，双方通过信令服务器交换这些候选地址
通信双方使用这些候选地址进行连接测试，确定最佳的可用地址
一旦找到可用的地址，通信双方就可以开始实时音视频通话

在WebRTC中网络信息通常用candidate来描述

针对上面三个问题的总结: 就是通过 WebRTC 提供的API 获取各端的媒体信息 SDP 以及网络信息 candidate并通过 信令服务器交换，进而建立了两端的连接通道完成实时视频语音通话。

常用的API

音视频采集getUserMedia（采集摄像头、喇叭里面的数据）
核心对象 RTCPeerConnection（RTCPeerConnection作为创建点对点连接的API,是我们实现音视频实时通信的关键

媒体协商方法 createOffer createAnswer setLocalDesccription setRemoteDesccription
重要事件 onicecandidate onaddstream

整个媒体协商过程可以简化为三个步骤对应上述四个媒体协商方法:

呼叫端创建 Offer(createOffer)并将 offer 消息(内容是呼叫端的 SDP 信息) 通过信令服务器传送给接收端,同时调用 setLocalDesccription 将含有本地SDP 信息的 Offer保存起来
接收端收到对端的 Offer信息后调用 setRemoteDesccription 方法将含有对端 SDP 信息的 Offer 保存起来并创建Answer(createAnswer)并将Answer 消息 (内容是接收端的SDP 信息)通过信令服务器传送给呼叫端
呼叫端收到对端的Answer 信息后调用setRemoteDesccription 方法将含有对端SDP 信息的Answer 保存起来
经过上述三个步骤，则完成了 P2P 通信过程中的媒体协商部分，实际上在呼叫端以及接收端调用setLocalDesccription 同时也开始了收集各端自己的网络信息(candidate)，然后各端通过监听事件onicecandidate 收集到各自的 andidate 并通过信令服务器传送给对端，进而打通P2P 通信的网络通道，并通过监听onaddstream 事件拿到对方的视频流进而完成了整个视频通话过程

graph TD
P2P-->解决三个问题---webSocket实现信令服务器 --> SDP了解对方支持的媒体格式实现不同编解码能力的音视频沟通 -->利用ICE机制找到能联系上对方的IP地址

音视频采集getUserMedia-->SDP了解对方支持的媒体格式实现不同编解码能力的音视频沟通
RTCPeerConnection作为创建点对点连接的API-->P2P

graph TD

ICE的工作原理---通信双方收集本地网络地址包括私有地址和公共地址以及通过STUN和TURN服务器获取的候选地址-->双方通过信令服务器交换这些候选地址 --> 通信双方使用这些候选地址进行连接测试-->确定最佳的可用地址-->一旦找到可用的地址通信双方就可以开始实时音视频通话

graph TD

完成整个视频通话过程-->setLocalDesccription同时也开始收集各自的网络信息candidate-->通过监听事件onicecandidate-->收集到各自的andidate-->通过信令服务器传送给对端-->进而打通P2P通信的网络通道-->通过监听onaddstream事件拿到对方的视频流-->完成整个视频通话过程-->交换SDP的整个媒体协商过程

A为呼叫端-->交换SDP的整个媒体协商过程
B为接收端-->交换SDP的整个媒体协商过程-->A

A-->createOffer-->通过信令服务器将内容是A的SDP信息的offer消息传给B-->B
createOffer-->同时setLocalDesccription-->保存含有本地SDP信息的Offer


A-->A收到对端Answer信息-->setRemoteDesccription保存含有对端SDP信息的Answer

B收到A的Offer信息---同时createAnswer---通过信令服务器传送内容是B的SDP信息的Answer消息给A-->A

B-->B收到A的Offer信息-->setRemoteDesccription保存含有A的SDP信息的Offer

graph TD
完成整个视频通话过程-->解决三个问题---webSocket实现信令服务器 --> SDP了解对方支持的媒体格式实现不同编解码能力的音视频沟通 -->利用ICE机制找到能联系上对方的IP地址
ICE的工作原理-->利用ICE机制找到能联系上对方的IP地址
ICE的工作原理-->通信双方收集本地网络地址包括私有地址和公共地址以及通过STUN和TURN服务器获取的候选地址-->双方通过信令服务器交换这些候选地址 --> 通信双方使用这些候选地址进行连接测试-->确定最佳的可用地址-->一旦找到可用的地址通信双方就可以开始实时音视频通话

音视频采集getUserMedia-->交换SDP的整个媒体协商过程
RTCPeerConnection作为创建点对点连接的API-->完成整个视频通话过程






完成整个视频通话过程-->setLocalDesccription同时也开始收集各自的网络信息candidate-->通过监听事件onicecandidate-->收集到各自的andidate-->通过信令服务器传送给对端-->进而打通P2P通信的网络通道-->通过监听onaddstream事件拿到对方的视频流-->完成整个视频通话过程-->交换SDP的整个媒体协商过程

A为呼叫端-->交换SDP的整个媒体协商过程
B为接收端-->交换SDP的整个媒体协商过程-->A

A-->createOffer-->通过信令服务器将内容是A的SDP信息的offer消息传给B-->B
createOffer-->同时setLocalDesccription-->保存含有本地SDP信息的Offer


A-->A收到对端Answer信息-->setRemoteDesccription保存含有对端SDP信息的Answer

B收到A的Offer信息---同时createAnswer---通过信令服务器传送内容是B的SDP信息的Answer消息给A-->A

B-->B收到A的Offer信息-->setRemoteDesccription保存含有A的SDP信息的Offer

webRTC原理

实现原理

1. 如何发现对方（信令服务器）

2.不同的音视频编解码能力如何沟通?（SDP）

3.如何联系上对方?（利用ICE 机制找到能联系上对方的IP地址）

ICE的工作原理如下:

常用的API