OSSのWebRTC SFU mediasoup v3のコードを読む（クライアント編）

コードの入手

すでに`master`ブランチがv3に向いてるので、そのまま`git clone`すれば落ちてきます。

サーバー実装の`master`はまだv2.xなので、むしろなぜ・・って感じではある。
近いうちにv3になるんでしょうね。

コードの雰囲気

読み込む前にいわゆるOverviewを。

READMEに書いてあるコードをそのまま抜粋。

import { Device } from "mediasoup-client";
import mySignaling from "./my-signaling"; // Our own signaling stuff.

// Create a device (use browser auto-detection).
const device = new Device();

// Communicate with our server app to retrieve router RTP capabilities.
const routerRtpCapabilities = await mySignaling.request(
  "getRouterCapabilities"
);

// Load the device with the router RTP capabilities.
await device.load({ routerRtpCapabilities });

// Check whether we can produce video to the router.
if (!device.canProduce("video")) {
  console.warn("cannot produce video");

  // Abort next steps.
}

// Create a transport in the server for sending our media through it.
const {
  id,
  iceParameters,
  iceCandidates,
  dtlsParameters
} = await mySignaling.request("createTransport");

// Create the local representation of our server-side transport.
const sendTransport = device.createSendTransport({
  id,
  iceParameters,
  iceCandidates,
  dtlsParameters
});

// Set transport "connect" event handler.
sendTransport.on("connect", async ({ dtlsParameters }, callback, errback) => {
  // Here we must communicate our local parameters to our remote transport.
  try {
    await mySignaling.request("transport-connect", {
      transportId: sendTransport.id,
      dtlsParameters
    });

    // Done in the server, tell our transport.
    callback();
  } catch (error) {
    // Something was wrong in server side.
    errback(error);
  }
});

// Set transport "produce" event handler.
sendTransport.on(
  "produce",
  async ({ kind, rtpParameters, appData }, callback, errback) => {
    // Here we must communicate our local parameters to our remote transport.
    try {
      const { id } = await mySignaling.request("produce", {
        transportId: sendTransport.id,
        kind,
        rtpParameters,
        appData
      });

      // Done in the server, pass the response to our transport.
      callback({ id });
    } catch (error) {
      // Something was wrong in server side.
      errback(error);
    }
  }
);

// Produce our webcam video.
const stream = await navigator.mediaDevices.getUserMedia({ video: true });
const webcamTrack = stream.getVideoTracks()[0];
const webcamProducer = await sendTransport.produce({ track: webcamTrack });

ざっくり書くと、

• `Device`の初期化
• サーバー側で対応してるコーデックやらRTPの要件を確認
• それがこちらの環境でも使えるかチェック
• サーバーから接続に必要な情報をサーバーからもらう（ICE/DTLS）
  • サーバー側でOffer作って投げるイメージ
• それを使ってトランスポートを作る（ここでは送信専用）
• そこに対してメディアをつなぐ
  • トランスポートに対して`MediaStreamTrack`を
• そしてローカルの接続情報をサーバーに送る
  • SRDしてAnswer作って投げるイメージ
• その後は`Producer`を介してやりとり

なのでこの送信専用のサンプルコードの登場人物として重要なのは、`Device`, `Transport`, `Producer`の3つで、順に依存関係がある。

`MediaStream`ではなく`MediaStreamTrack`をそのままI/Oに使ってるのもポイント。
うーん、ORTC・・！

それを踏まえてコードを読んでいく。

ファイル一覧

.
├── CommandQueue.js
├── Consumer.js
├── Device.js
├── EnhancedEventEmitter.js
├── Logger.js
├── Producer.js
├── Transport.js
├── detectDevice.js
├── errors.js
├── handlers
│   ├── Chrome55.js
│   ├── Chrome67.js
│   ├── Chrome70.js
│   ├── Edge11.js
│   ├── Firefox60.js
│   ├── ReactNative.js
│   ├── Safari11.js
│   ├── Safari12.js
│   ├── ortc
│   │   └── edgeUtils.js
│   └── sdp
│       ├── RemotePlainRtpSdp.js
│       ├── RemotePlanBSdp.js
│       ├── RemoteUnifiedPlanSdp.js
│       ├── commonUtils.js
│       ├── plainRtpUtils.js
│       ├── planBUtils.js
│       └── unifiedPlanUtils.js
├── index.js
├── internals.js
├── ortc.js
└── utils.js

ディレクトリはフラットで、さっきの依存関係は察せない。
むしろクロスブラウザ対応っていつの時代も大変よね・・っていう感じが押し出された構造になってる。

モジュールとしての`main`である`index.js`がエクスポートしてるのは、

• `Device`: `Device.js`
• `version`: ただのバージョン番号

なので、いわゆるエントリーポイントは`Device`クラス。

v2.x時代は他にも関数があったりしてたと思うので、そこが整理された感。

Device

エンドポイントごとに1つ存在する概念。

いま使ってるブラウザならブラウザ、Nodeならそのプロセスって感じかな？

`Device`は唯一の引数として`Handler`を受け取るようになってて、ブラウザから利用する場合はデフォルトのものがUAによって用意される。

その処理をしてるのが`detectDevice.js`。

• ReactNativeの場合は`RTCPeerConnection`がないとダメとか
• Chrome/Firefox/Safariに関してはバージョンごとに違うものを
• 非対応な場合は`null`が返って、`Device`のインスタンスが作れずに`throw`される

Transport

• `send`/`recv`どちらかの役割になる
• さっきの`Handler`が内部的に使われる
• メディアを送信・受信するようの処理
  • `send`の`Transport`なら`produce()`
  • `recv`の`Transport`なら`consume()`
• ICEの管理
  • `restartIce()`
• `getStats()`も生えてる

あとはこの`Transport`に対してイベントハンドラを設定しておくと、後述する処理でフックされてP2Pがつながる。

Producer / Consumer

`Producer.js`が送信メディアを管理するクラス。

• 単一の`MediaStreamTrack`の面倒を見る
• `replaceTrack()`/`close()`
• `pause()`/`resume()`でミュート/解除できる
• `this.track`で取れる`MediaStreamTrack`を、画面には描画する

`Consumer.js`が受信メディアを管理するクラス。

• 単一の`MediaStreamTrack`の面倒を見る
• とはいえ受信専用なのでできることは少ない
  • `close()`
• `pause()`/`resume()`でミュート/解除できる
• `this.track`で取れる`MediaStreamTrack`を、画面には描画する

その他

読んでみて

そういえばORTCってこんな感じでしたね・・！

• `Device`を1つ作って
• そこから`Transport`をつなげていく
• メディア送信用の`Transport`とその`Producer`
• メディア受信用の`Transport`とその`Consumer`
• `Producer`/`Consumer`は`MediaStreamTrack`が紐づくので、それを画面に出す

送受信で`RTCPeerConnection`を2つ使うの、コードを分離できるメリットがあるのでなるほどな〜という感じ。

• send:video + send:audio = 2pc
  • sendTransportで1pc
    • sendonly <-> recvonly
  • recvTransportで1pc
    • recvonly <-> sendonly
    • 部屋に入ると = consumeすると動き出す
• Transportを用意するときに方向が決まってる
  • `send` or `recv`
  • `send`で作ったTransportは`produce()`しかできない
• send(video+video+audio)の場合
  • sendTransportは1つでよい
• つまりPCは、送信で1つ、受信で1つ
  • 最低1つあればいい
  • それ以上は分けてもいいが、分ける必要はないかも

APIもコードもシンプルでシュッとしてて、WebRTCのJSのAPIも熟知しながらSDPをハックしていく感じでお見事！参考にさせていただきます！というコードでした。

サーバー側も踏まえて、SDPと各メディアをどのように紐付けて扱えばいいかは、サーバー編があればそっちで書こうかと。