4-6.完美协商

那在上节课中呢？我已经向你详细讲述了媒体协商的全部过程，那今天呢，我们再介绍另外一种媒体协商的方式。称为完美协商，那这时候可能大家会问完美协商又是什么？

它与我们前面介绍的媒体协商又是怎样的关系？那下面呢，我就给大家做一下详细解释，那实际上我们前面介绍的媒体协商过程可以称为传统的媒体协商过程。那对于传统的媒体协商来说呢，它存在一些问题，

我们来看一下都存在哪些问题，那第一个问题呢，就是老的协商方式。容易产生错误，那这个错误原因是什么导致的呢？实际上在外边其实内部为了更好的实现媒体协商，它维护了一个状态机。也就是说，

当我们处于媒体协商的不同阶段的时候，它的状态是不一样的。那假设通讯双方由于某种原因。都同时发送了offer给对方，而此时对方由于已经创建了offer，所以他的状态呢，就发生了变化。

那当它在收到offer类型的sdp的时候呢，就会产生冲突。这是初学者经常遇到的一些问题，那第二个问题呢？是我们要避免让双方同时发送offer。那就要在我们的逻辑代码中对协商进行处理，对吧？

这样使得业务逻辑混杂了协商代码，那这种代码编写方式呢？就显得非常差了，对吧？那对于我们开发同学来说呢，都知道一个基本的原理。就是高内聚低偶合，那我们在写逻辑代码的时候呢，

就应该关注在逻辑上，而不应该关注媒体的协商，对吧？这样让两者分别处理各自的事儿，就是一个好的设计，反之如果把它们混杂在一起，那这就是一个非常差的设计。正是因为传统协商带来了这些问题，

所以在新的webrtc中呢，提供了一种新的协商的方式，称为完美协商。那我们在介绍完美协商之前啊，我们先来看一下媒体协商的状态机，那刚才我在进行传统媒体协商问题描述的时候呢，实际就是按照这个状态机进行描述的。

对于webrtc来说，初始的时候，它的状态机就是稳定状态stable，对吧？当它创建offer之后呢，就变成了have local offer。这个时候，如果当前用户又收到了对端的offer消息，我们就可以看到它的冲突，就产生了对吧？因为对于客户端来说呢，只有在稳定状态的时候。它才能接收对端的offer消息，而现在我们已经处于了have local offer状态，那这个时候呢，

媒体协商就会失败。从而导致我们后边儿的所有的流程都无法进行了，这就是我前面所讲的第一个问题的原因，那下面我们来看看，完美协商。

那对于完美协商来说呢，它是允许双方可以同时发送offer给对方的，这是第一点，那第二点呢，是由于web rtc底层的状态机并没有发生变化。所以，当通讯的双方各自收到offer消息之后，还要给它设置一个角色，一个是polite，另一个是impolite。

也就是说，一个有礼貌，一个是没礼貌的，那对于有礼貌的这一端来说，当他收到offer之后，他会自动进行退换。会产生一个answer，在发送给对端.

而对于无礼貌的角色来说呢，当他收到offer之后，他不管三七二十一，他就把这个offer直接抛弃掉。所以这是与我们传统协商不同的第二点，也就是说我们要给通讯的双方赋予不同的角色，一个是有礼貌的，

一个是无礼貌的。但是对于角色的设置是由我们人为规定的，而不是由它内部自己设置的，所以我们在进行媒体协商之前呢，应该将一端设成为有礼貌的角色，另一端呢，设成为无礼貌的角色，这是第二点，

那第三点呢？对于完美协商来说呢，它不再需要create offer和create answer这两个方法了。那取而代之的呢，是使用不带参数的set local description方法来创建offer，那么对端收到offer之后呢，会自动适配我应该。产生answer还是offer，这就是完美协商，

那下面我们就来看一个具体例子，首先我们来看一下发送端，当发送端可以进行媒体协商之后。他首先将making offer设成为true，那这个变量的作用呢？就是判断当当他正在创建offer的时候，又收到了对端的offer，那这时候呢，就会产生一个冲突。对吧，所以这里要设一个true。

一会我们再看下一段逻辑的时候，你就可以真正理解这个变量的作用了，

第二步呢，是调用site local description来创建offer，并把offer设置到自己的缓冲区中。

那第三步呢，是通过信令模块将创建好的offer发送给对端，这就是发送端。那对于接收端来说呢，当它收到一个description之后，那首先判断传来的这个描述与我本地是否有冲突。它的判断条件是什么呢？就是首先看它是不是一个offer，那如果是offer的情况下再判断我现在是否正在创建offer，如果我也正在创建offer。就产生了两个offer，这时候就有了冲突，

或者呢，是它已经创建完offer，它的状态机呢，已经不是stable状态了。那这个时候呢？说明也产生了冲突。

当产生冲突的时候，就要判断你的角色是什么了，那如果是无礼貌的角色，那当收到对端的offer之后呢，就应该把它忽略掉。对吧，如果是有礼貌的呢，我们就做下面的操作。对于接收端来说呢，

如果到了这一步，就说明他收到的媒体协商信息是OK的，所以他要调用set remote description。将这个信息呢设置到自己的本地缓冲区中，然后它再判断，如果对方传来的。这个描述信息是offer它在调用set local description，根据底层状态机产生answer。最终呢，通过信令将answer传输给对端，那通过上面的描述以及代码的讲解呢，相信你也知道完美协商与我们前面介绍的传统媒体协商之间的区别。以及它的作用了，对吧？那对于完美协商来说呢？

它可以减少我们在媒体协商时容易出现的错误，同时呢，可以将我们的业务逻辑与媒体协商的代码呢，进行一个分割。这样可以让业务更关注于业务的内部逻辑，而媒体协商呢？只做媒体协商的这一部分工作。而且媒体协商的过程也比以前简单很多好。

如有侵权，请联系我删除