WebRTC的规范对信令处理没有做强制要求，所以它具有很大的灵活性。但是在WebRTC的实践中，有个推荐的建立连接模式，基于该模式能够极大地规避网络建立连接失败的现象，这个模式就是完美协商。
完美协商模式能够使协商过程与应用程序解耦。P2P建立连接的协商过程是天生不对称的操作，一方需要充当“呼叫者”，而另一方则是“被呼叫者”。完美协商模式将建立连接过程分为两个独立的协商逻辑，以此来消除协商过程的不对称性，因此应用程序无须关心连接的是哪一端。就应用程序而言，无论是呼出还是接听，都没有区别。
在完美协商模式下，调用方和被调用方都使用相同的代码，无须重复编写任何级别的协商逻辑。
完美协商模式的工作原理是在WebRTC建立连接协商过程中，为两个对等方分配不同的角色。
采用ICE回滚的方式防止收到提案时可能导致的SDP冲突。如果礼貌方发出提案的同时对等方也发出了提案，这时可能造成SDP冲突，此时礼貌方会放弃自己的提案，尝试应用对等方的提案。
当SDP冲突发生时，失礼方总是忽略对等方传入的提案，并且不向对等方做任何回应。
通过角色的区分，两个对等方都确切知道当冲突发生时应该如何应对，这使错误处理变得更加可控。
那么如何确定两个对等方的角色呢？我们可以简单地根据连接到信令服务器的时间先后进行分配，也可以使用随机数进行分配，这完全取决于应用程序的行为。
需要注意的是，在完美协商期间，呼叫者和被呼叫者的角色可以互换。如果礼貌方是呼叫者，并且发送了提案，但是与失礼方发生了冲突，则礼貌方会放弃自己的提案，并响应失礼方的提案。这样一来，呼叫者变成了失礼方，而礼貌方就从原本的呼叫者变为被呼叫者。
我们来看一下不使用完美协商模式的代码可能带来的问题。下面的代码清单实现了 onnegotiationneeded 事件处理逻辑。
//不使用完美协商模式的onnegotiationneeded示例
pc.onnegotiationneeded = async () => {
try{
await pc.setLocalDescription(await pc.createOffer());
signaler.send({description: pc.localDescription});
} catch(err) {
console.error(err);
}
}; 由于createOffer()方法是异步的，通常需要花费一些时间才能完成，而在此期间，对等方也有可能尝试发送提案，从而导致信号状态signalingState从stable变为have-remote-offer，这意味着我们需要马上响应对等方的提案，而此时我们的代码正在发出提案。
对等方也会出现同样的问题，对等方发出了提案，而随后也将收到我们发出的提案。 这个状态使双方都无法完成连接建立。
我们引入一个变量 makingOffer 来解决冲突问题，该变量为真值时表示我们正处于发送提案并调用 setLocalDescription()方法的过程中，如下面的代码清单所示。
//使用完美协商模式的onnegotiationneeded示例
let makingOffer = false;
pc.onnegotiationneeded = async () => {
try{
makingOffer = true;
await pc.setLocalDescription();
await signaler.send({description: pc.localDescription});
} catch(err) {
console.error(err);
} finally {
makingOffer = false;
}
}; 我们在程序的第一步即锁定makingOffer(设为false)，直到本地提案发送到对等端或者出现错误，再将makingOffer 放开，这样做能够避免提案冲突的风险。
在收到信令服务器的消息处理句柄onmessage中，使用makingOffer对本地提案锁定状态进行判断，如下面的代码清单所示。
//使用完美协商模式的onmessage示例
let ignoreOffer = false;
signaler.onmessage = async ({ data: { description, candidate }}) => {
try {
if (description) {
const offerCollision = (description.type == "offer") &&
(makingOffer || pc.signalingState != "stable");
ignoreOffer = !polite && offerCollision;
if (ignoreOffer) {
return;
}
await pc.setRemoteDescription(description);
if (description.type == "offer") {
await pc.setLocalDescription();
signaler.send(description: pc.localDescription);
}
} else if (candidate) {
try {
await pc.addIceCandidate(candidate);
} catch(err) {
if (!ignoreOffer) {
throw err;
}
}
}
} catch(err) {
console.error(err);
}
}; 我们在 onmessage 的实现中，用到了WebRTC的一些不常用的特性。
如果接收到对等方的消息是description，我们将检查它是否正好在本地尝试发送提案时到达。如果接收到的消息类型是offer，并且signalingState不是stable，此时我们就知道出现 SDP 冲突了。
如何处理冲突取决于本地的对等方角色类型，当本地是失礼方时，我们将忽略对等方的提案，并且不做任何回应，看看，这是不是不太礼貌?
礼貌方的行为与未发生冲突时是一致的，将远程描述description传递给setRemoteDescription()方法，并且将本地描述通过信令服务器发送给对等方以响应提案。
如果接收到的消息是ICE候选者，则流程会简单得多，不需要再对对等方的角色进行判断，调用 addIceCandidate()方法添加候选者信息即可。
在处理ICE重启时，有一种常见的错误做法是主动触发onnegotiationneeded事件句柄如下面的代码清单所示。
//主动触发onnegotiationneeded事件句柄示例
pc.onnegotiationneeded = async options => {
await pc.setLocalDescription(await pc.create0ffer(options));
signaler.send({ description: pc.localDescription });
};
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === "failed") {
pc.onnegotiationneeded({ iceRestart: true });
}
}; 这种做法是在WebRTC连接状态变为failed时，主动调用onnegotiationneeded 事件句柄，并为createOffer()方法传入参数iceRestart:true。正常情况下这是可以成功的，但是在异常情况下，如果此时signalingState信号不是stable，则会导致createOffer()创建本地会话描述失败，从而导致ICE重启过程失败，所以说这种做法是不可靠的。
为了解决这个问题，WebRTC在新的版本里增加了restartIce()方法。使用该方法可以较为可靠地进行ICE重启，如下面的代码清单所示。
//主动触发onnegotiationneeded事件句柄示例
pc.onnegotiationneeded = async options => {
await pc.setLocalDescription(await pc.create0ffer(options));
signaler.send({ description: pc.localDescription });
};
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === "failed") {
pc.restartIce();
}
}; restartIce()方法告诉ICE层将iceRestart标记自动添加到下一条发送的ICE消息中，并在合适的时机触发negotiationneeded事件，整个ICE重启过程是异步进行的，避免了因signalingState信号不是stable而导致createOffer失败的问题。