17 媒体协商过程

我们要弄清楚媒体协商过程，首先要认识我们WebRTC中最重要的一个类RTCPeerConnection。

1. RTCPeerConnection
   下面我们介绍一下最关键的概念就是RTCPeerConnection，其实在一开始的时候就给大家做了一个简单的介绍，这个类是整个WebRTC的一个核心类，它是上层的一个统一的接口，但是在底层做了非常多的复杂逻辑，包括了整个媒体的协商，流和轨道的处理，接收与发送，统计数据，都是由这一个类来处理的，所以对上层来说，你可能简单的调用了这个类或者里面的几个简单的API，但是实际在底层做了大量的工作，所以这个类是整个WebRTC的一个核心，我们一定要把这个类弄清楚，下面我们看一下这个类它的基本形式是什么样的：pc = new RTCPeerConnection([configuration];
   其实也比较简单，在我们创建这个对象的时候就是new一个RTCPeerConnection,它带一个配置参数，这个参数是可选的，就是可有可无，在我们后面的这个例子里，首先是没有参数的，看它是什么样子的，后面我们在看有参数的时候是什么样子的，但是我们就想用创建这个对象，直接就new一个这个对象就好了，这是它的基本格式，非常简单。
   RTCPeerConnection这个类我们可以将它的方法按分类分成下面的四类：
   1 媒体协商：主要是有四个方法，后面会详细介绍，通过这4个方法之后呢，我们就拿到了整个双方之间的媒体信息，然后他们会进行交换，然后去协商那你用的编码器是吗对吧，我用的这个编码器承包你用的音频格式，什么什么我用的音频格式，大概协商一致之后，他才真正地进行数据传输与编解码。
   2 Stream/Track：在整个WebRTC当中，每一路它是一路流，这个流里面有很多轨，有音频轨和视频轨，多路音频轨多路视频轨，在此前MediaStream 那节中已经做过介绍，那在这里是同样的理念，在传输中我们传输的就是Stream和轨，在轨道中就包含了音频数据和视频数据。
   3 传输的相关方法：就是我们用的是什么协议去传输RTP协议，RTCP协议。HTTP协议，那么通过这个链路的质量好坏，通过HTTP，然后进行反馈。再通过这个数据的统计分析，查看你整个链路的质量是怎样的，是不是已经发生拥塞了？还是说本身的你这个链路就是不太好的，都可以通过这个传输相关的方法来获取到去计算。
   4 统计相关方法：包括你的这个编解码器，你的这个音频格式，视频格式，你的这个整个传输相关的数据都可以通过这个统计相关的方法。后续也会一一看到怎么通过这些方法来获取到这些数据，来为我们真正的这个产品的质量提供帮助。
2. 媒体协商：主要是有四个方法，后面会详细介绍，通过这4个方法之后呢，我们就拿到了整个双方之间的媒体信息，然后他们会进行交换，然后去协商那你用的编码器是吗对吧，我用的这个编码器承包你用的音频格式，什么什么我用的音频格式，大概协商一致之后，他才真正地进行数据传输与编解码。
   Stream/Track：在整个WebRTC当中，每一路它是一路流，这个流里面有很多轨，有音频轨和视频轨，多路音频轨多路视频轨，在此前MediaStream 那节中已经做过介绍，那在这里是同样的理念，在传输中我们传输的就是Stream和轨，在轨道中就包含了音频数据和视频数据。
   传输的相关方法：就是我们用的是什么协议去传输RTP协议，RTCP协议。HTTP协议，那么通过这个链路的质量好坏，通过HTTP，然后进行反馈。再通过这个数据的统计分析，查看你整个链路的质量是怎样的，是不是已经发生拥塞了？还是说本身的你这个链路就是不太好的，都可以通过这个传输相关的方法来获取到去计算。
   统计相关方法：包括你的这个编解码器，你的这个音频格式，视频格式，你的这个整个传输相关的数据都可以通过这个统计相关的方法。后续也会一一看到怎么通过这些方法来获取到这些数据，来为我们真正的这个产品的质量提供帮助。

媒体协商过程
媒体协商的过程在我们使用RTCPeerConnection这个方法之前呢，我们要了解他的协议是什么，媒体是怎样协商出来的？

我们再看这些API的时候就知道这个调用是非常简单了，否则的话，你即使拿到了这些API，也不知道怎么用。但是它的协商过程呢，就如这张图所示

对于这两个端来说，一个假设是A，第二个是B。
A首先是要创建一个offer，创建offer之后呢，实际就形成了一个SDP在我们之前的课程都已经给大家做了一个简单介绍，SDP是什么，它是包含了一些媒体信息和编解码信息，包括这个传输的相关的信息。
A创建了一个offer，这个offer就是SDP的一种描述格式去描述的，创建完了之后，它通过云端的信令Channel让它传给谁呢？
传给B，但是传之前的那他还要调一个方法：
就调setLocalDescription，那他调这个方法是干什么呢？
他会触发一个非常重要的动作，大家一定要记住，就是setLocalDescription会触发一个非常重要动作就是去收集candidate，就是收集候选者。
当我们去创建这个连接之前，我们首先要拿到所有的那种候选者，就收集候选者，那怎么收集呢？
实际我是像这个stun或者是turn发送一个请求，咱们在这个请求过程中呢，我会拿到我本地的IP地址，还有通过NAT之后反射的这个地址以及TURN服务的中继地址。
那它是什么时候触发的呢？什么时候去触发去获取这些候选者呢？
就是通过这个setLocalDescription这个方法，当这个方法一调用就开始做这件事儿了，当然是并行的，其实这些事儿就通知去做这件事儿，同时呢，他就将这个offer通过信令服务发给了这个B端。
B端收到这个offer之后，就调用了那个setRemoteDescription，将这个offer所形成的SDP的这个数据放到自己远端的这个描述信息的槽里，对他是成为一个槽儿，这样就好了。
但这步做完之后呢，他做什么事儿呢？
他要回一个answer，也就说他要通过这个PeerConnection就是通过这个链接调用这个创建answer这个方法，也就是说创建一个我本身的这个媒体信息，也就offer的是A这个用户的整个机子的媒体信息,也就是我的编解码器，视频是什么、音频是什么？
我的这个与编解码相关的这个参数也都在里面形成了这个SDP传给B，B收到之后呢，把它放在他的远程的这个描述槽里之后呢，他自己在回个answer，这个answer回的是什么呢？
就是我本机我这个B这台机子所有的媒体信息，以及这个网络信息。那它也包括了它的支持的这个音频格式视频格式音频编解码器、视频编解码器，比如音频的参数双声道还是单声道，是这个采样率是一万六一还是三万二还是多少，它也形成这个，它调完之后它也形成这个setLocalDescription，它也做同样的事情，去触发收集候选者，我的这个网络有多少个候选者都要收集起来形成一个列表，调用这个函数之后它触发这个answer,通过这个信令服务就转给了A。
A收到这个answer之后它又把它存到这个setRemoteDescription，存到它的远程槽里，这样在每一端实际都有两个SDP，
第一个SDP是我自己的这个媒体信息，第二个SDP是描述对方的媒体信息。那个拿着这两个媒体信息之后呢，他在内部就进行一个协商，那看我支持的这些格式有没有你支持的，把这一协商之后呢，就取出他们的交集，
你支持的音频最好的是哪个呢？我支持的音频是什么？再取一个交集，同样视频也是，这是视频是什么？我支持的视频是什么？那取出这个交集之后，整个协商过程就算建立好了，这个时候他才能进行后面的操作，进行真正的编解码。
传输都传到对方之后，因为他们协商好了之后，但对方也知道这是我支持的，所以他也能进行解码，让他去渲染这个音频也好，视频就播放那个视频就渲染。这就是整个协商过程。
总的来说有四个步骤：
（1）每一端是有四个步骤：
创建offer，
设置LocalDescription，
然后是接收answer，
当设置RemoteDescription，这个调用方；

（2）被调用方也是一样有四个步骤：
就是先接收offer，
然后设置setRemoteDescription，
然后是创建answer上
设置setLocalDescription。

媒体协商方法

上面的媒体协商过程中主要用到了WebRTC中的四个方法：
createOffer
createAnswer
setLocalDescription
setRemoteDescription
下面我们对这几个方法详细介绍一下：
上面有详细介绍了媒体协商的整个流程：
其中有createOffer，就创建一个本地的这个媒体信息,音频编解码视频编解码等等。
对于这个对端呢，就是收到offer之后呢，它会创建一个createAnswer，这是第二个方法，
也就是说我本地的一个信息最终要传给这个调用者。那第三个就是setLocalDescription，
我把我自己本地的这个SDP的描述信息设置好之后我就可以触发去采集这个收集候选者了 。那第四个就是setRemoteDescription，
当受到对端的这个描述信息之后，SDP之后呢，将它设的setRemoteDescription这个槽儿里去，在内部他就做了这个真正的协商，就是媒体协商的方法。

1. createOffer

aPromise =  myPeerConnection.createOffer([options]);

它有一个可选的options,，它返回的是一个promise，它会创建成功之后有一个逻辑处理。创建失败也会存在另外一个逻辑处理。

2. createAnswer

aPromise = myPeerConnection.createAnswer([options]);

createAnswer，他的基本格式什么？
就是PeerConnection下边有一个方法就createOffer，那它有一个可选的option，这个option后面我们还会做详细的介绍，还有几个选项，每个选项都有其特殊的意义，他返回的是一个promise，它会创建成功之后有一个逻辑处理。创建失败也会存在另外一个逻辑处理，那这个createAnswer这个格式其实跟他是类似的，就变成了createAnswer，还有一个option，这个option其实就是作用不大，主要是createOffer是这个option有很多作用，setLocalDescription的格式就是将createOffer或者createAnswer的结果，包括参数设置到这里就设置好了，同样道理，setRemoteDescription。那这个格式也比较简单,也是刚那个对端的这个sessionDescription设置进来就好了。
3. setLocalDescription

aPromise = myPc.setLocalDescription(sessionDescription);

4. setRemoteDescription

aPromise = myPc.setRemoteDescription(sessionDescription);

用于将对端的SDP设置进来。
我们都知道视频和音频都是有轨道组成的，下面我们介绍一下一个轨道方法就是Tack方法。在RTCPeerConnection里就有两个重要的这个Track的方法，一个是添加，一个是移除，这个比较简单，
但我们来看看添加方法的格式就是：
第一个是你要添加的这个Track的是音频的Track还是视频的Track，
第二个是stream，那么这个stream从哪儿来呢？
实际就是我们之前介绍的getUserMedia那里我们会拿到一个流，这个流里面可能有音频Track有视频Track，那你就要遍历一下，让他们一个个都加入到这个PeerConnection里去，这样PeerConnection就可以控制这每一路轨了。就从他们那个里边儿可以获取到数据进行这个发送，这是添加。
那么他有一些参数。这个参数刚才我已经介绍,这Track就是媒体轨，这个stream的就是我们getUserMedia获取的stream。removeTrack这个比较简单，就是将Addtrack里头这个send放进去，然后他就可以这个移除掉了。
5. addTrack

rtpSender = myPc.addTrack(track,stream...);

6. remoteTrack

myPc.remoteTrack(rtpSender);

7. PeerConnection 事件
   PeerConnection还有几个比较重要的事件，我们这里重点介绍两个：
   第一个是这个协商事件：当我们那个进行媒体协商的时候，就会触发这个，onnegotiationneeded就是需要协商，只要协商的时候会触发这个事件。

第二个是onicecandidate，就是当我们收到一个ICE的候选者的时候，也会从底层触发这个事件，告诉我们现在有一个候选者来了，那么我们要拿到这个候选者，将它添加到我们的这个ICE里去，这样就可以进行这个ICE的这个通讯了。