WebRTC 完美协商模式

作者：追风剑情发布于：2024-2-23 11:16 分类：Unity3d

WebRTC的规范对信令处理没有做强制要求，所以它具有很大的灵活性。但是在WebRTC的实践中，有个推荐的建立连接模式，基于该模式能够极大地规避网络建立连接失败的现象，这个模式就是完美协商。

完美协商模式能够使协商过程与应用程序解耦。P2P建立连接的协商过程是天生不对称的操作，一方需要充当“呼叫者”，而另一方则是“被呼叫者”。完美协商模式将建立连接过程分为两个独立的协商逻辑，以此来消除协商过程的不对称性，因此应用程序无须关心连接的是哪一端。就应用程序而言，无论是呼出还是接听，都没有区别。

在完美协商模式下，调用方和被调用方都使用相同的代码，无须重复编写任何级别的协商逻辑。

完美协商模式的工作原理是在WebRTC建立连接协商过程中，为两个对等方分配不同的角色。

礼貌方(polite peer)

采用ICE回滚的方式防止收到提案时可能导致的SDP冲突。如果礼貌方发出提案的同时对等方也发出了提案，这时可能造成SDP冲突，此时礼貌方会放弃自己的提案，尝试应用对等方的提案。

失礼方(impolite peer)

当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的一些不常用的特性。

没有为setLocalDescription()方法指定参数。如果未指定参数，则WebRTC会自动创建一个会话描述，并作为该调用的参数默认传入。这在某种意义上实现了本地会话描述的原子操作。
setRemoteDescription()方法在出错时将自动回滚。

如果接收到对等方的消息是description，我们将检查它是否正好在本地尝试发送提案时到达。如果接收到的消息类型是offer，并且signalingState不是stable，此时我们就知道出现 SDP 冲突了。

如何处理冲突取决于本地的对等方角色类型，当本地是失礼方时，我们将忽略对等方的提案，并且不做任何回应，看看，这是不是不太礼貌?

礼貌方的行为与未发生冲突时是一致的，将远程描述description传递给setRemoteDescription()方法，并且将本地描述通过信令服务器发送给对等方以响应提案。

如果接收到的消息是ICE候选者，则流程会简单得多，不需要再对对等方的角色进行判断，调用 addIceCandidate()方法添加候选者信息即可。

再谈 ICE 重启

在处理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失败的问题。

标签: Unity3d