持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第30天，点击查看活动详情
简单地说，媒体协商就是看看你的设备都支持那些编解码器，我的设备是否也支持？如果我的设备也支持，那 么咱们双方就算协商成功了。
在 WebRTC 1.0 规范中，在双方通信时，双方必须清楚彼此使用的编解码器是什么，也必须知道传输过来的音视频流的 SSRC信息，如果连这些最基本的信息彼此都不清楚的话，那么双方是无法正常通信的。媒体协商的作用就是让双方找到共同支持的媒体能力，如双方都支持的编解码器，从而最终实现彼此之间的音视频通信。
媒体协商的基本步骤
- 首先，通信双方将它们各自的媒体信息，如编解码器、媒体流的 SSRC、传输协议、IP 地址和端口等，按 SDP 格式整理好。
- 然后，通信双方通过信令服务器交换 SDP 信息，并待彼此拿到对方的 SDP 信息后，找出它们共同支持的媒体能力。
- 最后，双方按照协商好的媒体能力开始音视频通信。
RTCPeerConnection
RTCPeerConnection 表示的就是端与端之间建立的连接。该类是整个 WebRTC 库中最关键的一个类，通过它创建出来的对象可以做很多事情，如 NAT 穿越、音视频数据的接收与发送，甚至它还可以用于非音视频数据的传输等等 。而在这里我们之所以要介绍 RTCPeerConnection，最主要的原因是我们今天要讲的端到端之间的媒体协商，就是基于 RTCPeerConnection 对象实现的。
在 JavaScript 下创建 RTCPeerConnection 对象非常简单
...
var pcConfig = null;
var pc = new RTCPeerConnection(pcConfig);
...
在通讯双方都创建好 RTCPeerConnection 对象后，它们就可以开始进行媒体协商了。
媒体协商过程
在进行媒体协商之前，有两个重要的概念，即 Offer 与 Answer ，你必须要弄清楚。
Offer 与 Answer 是什么呢？对于 1 对 1 通信的双方来说，我们称首先发送媒体协商消息的一方为呼叫方，而另一方则为被呼叫方。
- Offer，在双方通讯时，呼叫方发送的 SDP 消息称为 Offer。
- Answer，在双方通讯时，被呼叫方发送的 SDP 消息称为 Answer。
在 WebRTC 中，双方协商的整个过程如下图所示：
首先，呼叫方创建 Offer 类型的 SDP 消息。创建完成后，调用 setLocalDescriptoin 方法将该 Offer 保存到本地 Local 域，然后通过信令将 Offer 发送给被呼叫方。
被呼叫方收到 Offer 类型的 SDP 消息后，调用 setRemoteDescription 方法将 Offer 保存到它的 Remote 域。作为应答，被呼叫方要创建 Answer 类型的 SDP 消息，Answer 消息创建成功后，再调用 setLocalDescription 方法将 Answer 类型的 SDP 消息保存到本地的 Local 域。最后，被呼叫方将 Answer 消息通过信令发送给呼叫方。至此，被呼叫方的工作就完部完成了。
接下来是呼叫方的收尾工作，呼叫方收到 Answer 类型的消息后，调用 RTCPeerConnecton 对象的 setRemoteDescription 方法，将 Answer 保存到它的 Remote 域。
至此，整个媒体协商过程处理完毕。当通讯双方拿到彼此的 SDP 信息后，就可以进行媒体协商了。媒体协商的具体过程是在 WebRTC 内部实现的。本地的 SDP 和远端的 SDP 都设置好后，协商就算成功了。
WebRTC 提供的 API
**
**
浏览器提供了几个非常方便的 API，这些 API 是对底层 WebRTC API 的封装。如下所示：
- createOffer ，创建 Offer；
- createAnswer，创建 Answer；
- setLocalDescription，设置本地 SDP 信息；
- setRemoteDescription，设置远端的 SDP 信息。
