「这是我参与2022首次更文挑战的第1天，活动详情查看：2022首次更文挑战」。
媒体协商流程如下图所示，该图片完整的展示了 WebRTC 媒体协商的过程：
由图片可见，媒体协商是会有两个对象进行 offer 与 answer 的创建与互换，此图中，Amy 为呼叫方，Bob 为被会叫方（为了方便理解，下面将使用Amy、Bob为代称），一般前端为呼叫方，服务端为被会叫放，具体媒体协商流程如下：
前端创建 offer，服务端创建 answer，媒体协商流程如下：
Amy 方：
- 创建 offer
- offer 创建成功后，将创建好的 offer 设置 LocalDescription
- 通过网络请求，传输 offer，并获取 answer
Bob 方：
- 接收 offer
- 将获取到的 offer 设置 RemoteDescription
- 创建 answer
- answer 创建成功后，将创建好的 answer 设置 LocalDescription
- 将创建好的 answer，通过刚刚那个请求，传输出去
Amy 方：
- 将获取到的 answer 设置 RemoteDescription
- 完成媒体协商
以上，就是媒体协商的过程，不过这个 offer 的前端创建的，如果改为服务端创建 offer，前端创建 answer，协商该如何进行呢？
服务端创建 offer，前端创建 answer，媒体协商流程如下：
Amy 方：
- 发起网络请求，通知 Bob 创建 offer
Bob 方：
- 创建 offer
- offer 创建成功后，将创建好的 offer 设置 LocalDescription
- 通过网络请求，传输 offer
Amy 方：
- 将获取到的 offer 设置 RemoteDescription
- 创建 answer
- answer 创建成功后，将创建好的 answer 设置 LocalDescription
- 将创建好的 answer，发起网络请求，传输出去
Bob 方：
- 接收 answer
- 将获取到的 answer 设置 RemoteDescription
- 完成媒体协商
涉及到的 api
RTCPeerConnection()构造函数，返回一个新建的 RTCPeerConnection实例，它代表了本地端机器与远端机器的一条连接。
pc = new RTCPeerConnection([configuration]);
总结
媒体协商无非是 offer、answer 的创建、存储与互换的过程，看似繁琐，如果了解了其中的原理，其实很简单。
