河豚板でWebRTC†
- WebRTCによる通信(映像・音声を送受する機能)自体は、ウェブブラウザ同士で可能
- ただし、通信を成立させるためにはSTUN, TURN, ICEなどのプロトコルを実装したシグナリングサーバが必要
- ある程度以上のな配信を行うためには、MCU(Multipoint Control Unit)やSFU(Selective Fowarding Unit)などの配信サーバを設置する
- 詳細な資料: あさまさんのWebRTCについて調べてみた
山古志・春の牛まつり ~山古志で牛と太鼓と触れ合おう~佐渡から鼓童もやってくるよ! (2021/5/5)†
- 山古志の「闘牛」と佐渡の「鼓童」のコラボイベント
- 観客席へインターネットを介さずWiFiで直接配信 (Local 5G的な運用)
- 闘牛場のイベントMCと佐渡にいる鼓童リーダーとのトークの様子を見せるため
- 音声は場内PAを使用。それに合わせリアルタイムで映像配信しないといけないので、YouTubeなどは不可。
- 計画
- 閉じたネットワーク内でTLS通信を行うため、WebRTCのサーバ以外にも、DNS, DHCP, NTPなどを用意する必要がある。
- スマホが文句言わないように、制限した形でのNATを介してのインターネットアクセスも設定
- 当初はJitsiの使用を想定
- Node.jsでシグナリングサーバを自前で実装。動作したが、iPhone/iPadで画像が表示されない不具合が出た
- 音声の配信は必要なかったため、Screegoを採用 (さらに、OpenBSD用のバイナリも公式サイトからダウンロードできた)
 |  |
概念図 | 構成図 |
(クリックで拡大) |
- 運用
 |  |
配信ブース | WiFi AP |
 |  |
配信インフラ(Screego他、サーバ) | 配信PC |
クリックで拡大 |
- 事前テストでは、100弱の配信まで対応
- 実運用では、50~60程度で頭打ち(Screegoが落ちた → 再起動)
- Screegoを(動作をモニタリングするため)verboseなログ出力をしてたため?
... Screego自体はシグナリングサーバなので、配信数が増えても負荷はそれほど増加しない気がするが...
- 配信ブラウザにFirefoxを使用していたため?
... 途中からChromiumに切り替えたら負荷低下 → 解像度も若干落として運用継続
- 諸般の事情により実施は今回のみ、リベンジマッチならず