Не сработает ли кэширование кандидатов ICE и sdp, даже если мы точно знаем маршрут соединения?

Question

Я понимаю, что в P2P и более динамичной среде кэширование кандидатов ICE и sdp не будет хорошей практикой, потому что материал, который вы кэшируете, может не подать заявку на следующее соединение WebRTC.Но как насчет тех обстоятельств, когда мы точно знаем, каким должен быть маршрут соединения?

Чтобы быть более точным,

1. допустим, что у нас есть 1 сервер TURN (без нагрузки-балансировка, поэтому нет внутренней маршрутизации)
2. и 2 пира с фиксированным IP, которые хотели бы время от времени соединяться с WebRTC.

В этом случае мы точно знаем, каковы IP-адреса одноранговых узлов, и мы точно знаем, каков IP-адрес сервера TURN (при условии, что он не изменится), было бы нормально кешироватьКандидат ICE (TURN) и SDP или части SDP только для обхода кандидата ICE и части обмена SDP?

Answer 1

Нет.Предложения и ответы содержат больше, чем просто , как для подключения.Они содержат уникальный отпечаток для этого соединения экземпляр , поскольку можно установить любое количество безопасных соединений между одними и теми же двумя известными IP-адресами, даже одновременно.

Сравните createOffer () результат двух разных RTCPeerConnection объектов, и вы увидите, что они различаются.Помимо отпечатков пальцев, они также содержат информацию о том, какие порты локальный RTCPeerConnection решил отправлять / получать по отдельным носителям, что может варьироваться.

Чтобы использовать более раннюю кэшированную версию, вы должны указать, что нетолько удаленный RTCPeerConnection объект, какие порты использовать, но также и ваш локальный.И это явно не работает:

const [pc1, pc2, pc3] = [1,2,3].map(() => new RTCPeerConnection());

(async () => {
  try {
    [pc1, pc2].forEach(pc => pc.createDataChannel("dummy"));
    pc3.ondatachannel = () => console.log("pc3 ondatachannel");
    await pc1.createOffer();
    await pc1.setLocalDescription(await pc2.createOffer()); // Uh oh! pc2 not pc1
    await pc3.setRemoteDescription(pc1.localDescription);
    await pc3.setLocalDescription(await pc3.createAnswer());
    await pc1.setRemoteDescription(pc3.localDescription);
  } catch (e) {
    console.log(e);
  }
})();

pc1.onicecandidate = e => pc3.addIceCandidate(e.candidate);
pc3.onicecandidate = e => pc1.addIceCandidate(e.candidate);
pc1.oniceconnectionstatechange = e => console.log(pc1.iceConnectionState);
pc3.ontrack = e => video.srcObject = e.streams[0];

В последнем Chrome это дает:

InvalidModificationError: The SDP does not match the previously generated SDP for this type

..., что правильно, так как последняя спецификация WebRTC запрещает SDP в пределах от createOffer и setLocalDescription .

В Firefox согласование фактически завершается, но никакие события носителя или канала данных не запускаются.

Даже с сервером TURN обойти невозможночто отпечатки пальцев не будут совпадать.