WebRTCのPerfect negotiationについて

まえがき

• WebRTCのネゴシエーションは思った以上に複雑
  • SDPやICE candidateの交換
  • ステートフルな`signalingState`
  • TrickleICEのタイミング問題
  • etc...
• ただしなんとかする方法もある
  • 何も気にせず各エンドポイントが`addTrack()`すればいいだけにできる
• そのためには2つのピースが必要
  • `negotiationneeded`イベント
  • SDPのtype: `rollback`

しかし現状ではFirefoxでしか実装されておらず、実現できない・・。

negotiationneededを使おう

ブラウザがネゴシエーションが必要だと思われるAPIコールに応じて、自動的に発火してくれるイベント。
ICEのcandidateが見つかったときに、`icecandidate`イベントが発火するのと同じ。

送信側のコードのイメージ。

pc.onnegotiationneeded = async () => {
  await pc.setLocalDescription(await pc.createOffer());
  io.send({ description: pc.localDescription });
};

受信側はこう。

// candidateとSDPが飛んでくる
io.onmessage = async ({ data: { description, candidate }}) => {
  // SDP
  if (description) {
    await pc.setRemoteDescription(description);
    // オファーの場合は、アンサーを送り返す必要がある
    if (description.type == "offer") {
      await pc.setLocalDescription(await pc.createAnswer());
      io.send({ description: pc.localDescription });
    }
  }
  // candidate
  else if (candidate) await pc.addIceCandidate(candidate);
};

これだけ仕込んでおけば、後は任意のタイミングで`addTrack()`するだけで、自動的にネゴシエーションが行われる。

基本的にはこれだけでPerfectなんだが、いわゆるグレア（両側で同時に操作した場合）の問題が残る。

（ちなみに、Chromeでこのイベントがまともに発火するようになったのは割と最近・・）

そこでrollback

そもそもグレアは、アプリケーションレイヤーで解消できるものでもある。
ただし、WebRTCのレイヤーでも`rollback`を使えばなんとかできる。

端的にいうと、グレアに陥ったときに「お先にどうぞ」する紳士的な実装にすればよい。

// さっきのハンドラーをアップデート
io.onmessage = async ({ data: { description, candidate }}) => {
  // SDP
  if (description) {
    // オファーを受け取ったが、自分もオファーを出している状態だった
    if (description.type == "offer" && pc.signalingState != "stable") {
      // 礼儀正しいピアと、そうでないピアのP2Pになるようにしておく
      if (!polite) return;
      // 礼儀正しいならばロールバックして相手のオファーを優先
      await Promise.all([
        pc.setLocalDescription({ type: "rollback" }),
        pc.setRemoteDescription(description)
      ]);
    }
    // アンサーを受け取っただけ or 自分は何もしてないときにオファーを受けた
    else {
      await pc.setRemoteDescription(description);
    }

    // それがオファーならアンサーを送り返す
    if (description.type == "offer") {
      await pc.setLocalDescription(await pc.createAnswer());
      io.send({ description: pc.localDescription });
    }
  }
  // candidateはそのまま
  else if (candidate) await pc.addIceCandidate(candidate);
};

`polite`というフラグ変数だけ事前に用意して決めておく必要がある。

`rollback`のところで`Promise.all()`してる理由は、その隙間にICE candidateが飛んてくる可能性があるから。
ちゃんと`await`すれば、このPromiseが解消されたあとで`addIceCandidate()`が解消される。

これでまた一歩Perfectに近づいたけど、あと一歩足りない。

同じような処理を、`negotiationneeded`時にも考慮する必要がある。

pc.onnegotiationneeded = async () => {
  const offer = await pc.createOffer();
  // 相手のオファーを処理中
  if (pc.signalingState != "stable") return;
  await pc.setLocalDescription(offer);
  io.send({ description: pc.localDescription });
};

`return`しちゃったら呼ばれないまま消えちゃうのでは？と思うけど、`signalingState`が`stable`にもどったら、再度`negotiationneeded`が発火するので問題ない。

つらくない？

• その気持ちはわかる
• なので`Promise.all()`や`stable`かどうかの確認をスキップできるような仕様も提案してる
  • https://github.com/w3c/webrtc-pc/issues/2165
  • https://github.com/w3c/webrtc-pc/issues/2166
  • https://github.com/w3c/webrtc-pc/issues/2167
• ただ1回書いてしまえば、この実装は隠蔽できる
  • そしてアプリケーション要件に振り回されないところなはず
• WebRTCのAPIが内部的にそうやってくれればいいのでは？はごもっとも
  • ただハイレベルなAPIとローレベルなAPIへの需要はどちらもある
  • APIデザインとして決めきれなかったのは事実

pc.onnegotiationneeded = async () => {
  // これが非同期なので
  const offer = await pc.createOffer();
  // ここで相手からオファーが届いてしまう可能性がある

  // そうなるとコレが困る
  await pc.setLocalDescription(offer);
  io.send({ desc: pc.localDescription });
};

pc.onnegotiationneeded = async () => {
  io.send({ desc: await pc.setLocalDescription() });
};

await pc.createOffer();
await pc.setLocalDescription({ type: "offer" });

await Promise.all([
  pc.setLocalDescription({type: "rollback"}),
  pc.setRemoteDescription(description)
]);

なぜこれらが必要か

• ネゴシエーションの必要性を決めるアルゴリズムは、思ってる以上に複雑である
• たとえばアンサー側の`addTrack()`は`signalingState`によって挙動が変わる
  • `stable`に戻ったとき、利用可能な`Transceiver`の数に応じて変わる
  • 改めてネゴシエーションが必要な場合と不要な場合がある
• 手動でそういうのも管理できる？