在我们真正开始实现我们一对一的实时直播系统之前，我们再来看看这个RTCPeerConnection,在我们之前使用RTCPeerConnection的时候我们把这个参数设置成了null,或者不填，因为这个参数configuration本身是可以不填的
基本格式
pc = new RTCPeerConnection([configuration]);
其实它里面可以有很多的参数，在RTCconfiguration这个结构体里有好几项，
最关键的一项是iceServers,也就是说我们在建立这个RTCPeerConnection之前可以给他传入很多的iceServers，也就是我们的STUN和TURN服务，那么通过这个STUN和TURN服务可以做这个检测获取到相应的反射地址和中继地址，那些形成这些服务之后他就可以进行这些连接性检测的时候找出它的优先级，那么优先级我们上节就说了，在测试STUN和TURN服务的时候那个工具里就有这个优先级的显示；
第二项是iceTransportPolicy，也就是传输的策略，它的传输策略有两种，一种是all一种是relay。如果是all的话就支持host本机的地址，也就是穿越NAT反射后的candidate以及中继的candidate，如果是relay类型只收集中继类型的candidate也就是中继的通路，这是第二项。
第三项是bundlePolicy，bundlePolicy这个策略实际也有好几种，默认是balanced,也就是平衡的，后面我们会详细的介绍；
第四项是rtcpMuxPllicy的复用，复用策略，默认是require;
第五项peerIdentity就是一个标识的字符串，这里不用过多的讨论它。
第六项certificates就是一些证书，也就是我们每一个连接，每一个可连通的候选者都需要有一个证书，所以如果你有多个连接，你就有多个证书，但是一般情况下如果是复用的话，我就用一个证书就可以了，这样可以增加它建成整个传输的速度。
第七项就是iceCandidatePoolSize,也就是我要收集的候选者的空间有多大，默认是0；如果你设置成5的话，如果你有20个，那只选其中的5个。
那第一个呢，是这个bundlePolicy。那这个bundlePolicy策略，是有三种，一种是Balanced，一种是max-compat，然后还有一个是max-bundle的，那我们先看那个Balanced实际就是音频轨、视频轨各自是自己的一个传输通道，它是分开的，那这个如果有多路音频，多路视频，那音频的类型，都有音频的这个传输轨道存储的这个通道的。视频都有视频的传统。那第二个呢，就是max-compat是最大兼容性，怎样才能达到最大的兼容性呢？就是每一个轨都有自己的通道，如果我有这个两个音频，一个视频，就有三个带有三个通道，就是每个音频走自己的，那视频总可以吧。等到我们进行这个Balanced的时候，那时就走了这个max-compat这种方式。那最后一个呢，是max-bundle就是最大化的使用一个绑定，那就是将所有的这些这个媒体的这个流都用一个这个通道进行传输。这是这个建议，这是webrtc建议的这种方式，这样的话对于底层来说就比较简单了，而且你建立这个连接之后，你的证书是需要一个，不需要一堆，对吧，否则的话，你每一个连接都有证书，就会非常的耗费时间。
再下来就是证书，那就是certificates的，可以使用的，这个连接的一组，那我们可以提供这个，每个人接的证书也可以不提，我不提供的话就会自动产生，所以这个证书的话一般我们也不会设置
那接下来的是iceCandidatePoolSize,就是池子大小的16位的整数，用于指定预取的这个ICE候选者的个数。那么我们如果一旦设置了一个池，如果比池多的候选者，那么我们就不能放在这里了。多出来就不放了。那么他还有一个重要的一个功能，如果这个iceCandidatePoolSize它的值发生变化了，那么会重新收集候选者，比如最开始我设成了3，然后我紧接着设成了10，这个时候呢，它会在底层会重新触发这个收集候选者，就重新再来一遍，这其实也挺重要的，就是当我们发现这个链路，其实一开始我们建立了一个链路，但是这个链路由于网络原因发生拥塞了，一条路走不通了，那么我们可以改变这个值，让它触发，重新收集这个Candidate，然后想另外条路，这都是可以的
还有呢，再下一个是这个iceTransportPolicy,就是传输的策略。那传输策略呢，刚才我就给大家讲了它有两种，一种是那个relay就是中继，他就说我只收集就是收集这个候选者的时候，只收集这个中继的候选者。因为在真实的网络情况下，就是中继的这个候选者，NAT穿越在中国实现比较困难，所以呢，一般都是使用relay。然后还有all，就是说我的这个hosts的类型儿的，NAT穿越反射的类型，以及这个relay类型的都要收集，这是它的不同的策略，但是我们一般用all
那还有下来就是iceServers，那么就说有一组，它有一组那个RTCIceServer组成，哪个每一个IceServer这个都是一个ICE代理服务器，你就把它认为是这个ICE的一个candidate。那它包括什么呢？它包括了这个credential,这个凭证的实际，他的是一个双层的双层含义的，会根据下面这个credentialType类型儿，然后去处理他，如果是他password的，那么这个属性就是password，如果他是那个oauth的，它这个值就是他是一个结构体，那这个结构体也就包括了一个Key，还有一堆证书。所以他是根据credentialType这个类型儿然后来看他的credential的值，在下来的就是urls，比如说我们设置的这个STUN和这个TURN服务，对吧，如果有的话，每一个都是一个url串，通过这个url串我们可以访问到这个地址，STUN和那个TURN服务，最后一个用户名，跟那个credential这个是匹配的，一个用户名一个密码
那带下来的就是rtcpMuxPolicy这个复用策略policy。但它有两个呢，第一个是negotiate协商，就是收集RTCP和这个RTP复用的这个ICE候选者,就是看能不能在尽量去这么收集，他俩能复用的ICE的候选者，如果不能复用，那么就将他们单独出来各自走各自的通道，就那么RTP走RTP的，RTCP走RTCP的就好了，那默认的是require，就是我就一定要收RTP和RTCP服用的ICE，这样的这些候选者我才真正使用，那么如果他们不能复用，那就失败。
addIceCandidate
在接下来我能介绍一下addIceCandidate，实际我们之前就已经介绍过了，并且开始使用了，我们在看一下它的基本格式
基本格式
aPromise = pc.addIceCandidate(candidate);
pc就是RTCpeerConnection
candidate类型里面包括的属性如下
那么candidate这个类型包括哪些属性呢？就是包括那个candidate候选者，描述信息；
sdpMid代表着每一路流，这个ID之前在讲SDP的时候给大家介绍过，比如说我们那个视频是video就是0啊，那么sdpMLineIndex，这是M等于号的索引值，它是第几个M？比如说我们在这个SDP中一共有两个，一个视频，一个音频，那么的视频是第一个，音频是第二个，那么引入音频的话，就是2，视频的就是1。这个usernameFragment大家还记得，就是我们那个在验证的时候有一个ICE uflag其实就是这个，了解了以上这些信息之后呢，然后我们就可以对我们之前的这个端对端进行音视频传输的例子都修改了，然后再加上我们的信令服务器，再加上这个STUN和TURN服务，这样我们就能做出一个真正的一对一的音视频实时互动直播系统，
