Multistream を勝手にまとめる

Firefox 38 で実装された WebRTC の Multistream という機能。これを勝手にまとめてみます。

まずは以下を読める人は読みましょう。

なんとなーくわかったら、次はこちらを読みましょう。

Negotiating Media Multiplexing Using the SDP
https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-20

まとめます

  • ブラウザの API 側では簡単に既存のコネクションに対してストリームを動的に追加したり削除したりすることが出来るようになった
  • つまりビデオ+音声に加えスクリーンシェアなどを一つの接続で扱えるようになった

WebRTC SFU 視点で見てみると、とても良い仕組みであることがわかります。

  • 今までは上り 1 下り N (参加人数から自分を引いた値) だったのが 1 本の DTLS を SFU に貼るだけで良くなりました。
  • ただし今までのようなシグナリングの仕組みは使えなくなり、DTLS 内部でのセッションを Adding/Moving するためのシグナリングの仕組みが必要になります

SFU は今までの仕組みではアップロード用に一つ接続をはっておけば、SFU が他の人に配ってくれていました。さらに残りのメンバー分の接続は一つ一つ下りように接続を貼る必要がありました。

下の図では一つの矢印がそれぞれ DTLS セッションです。つまり暗号接続を 3 本はることになります。

Image for post
Image for post

ただ Multistream を使った SFU への接続は DTLS セッションは 1 本になります。その中で RTP セッションが複数貼られるようになるのです。

つまり SFU サーバとしては DTLS セッションが減らせるというメリットはあります。ただし管理はもっと面倒くさくなりますが … 。

この流れは止まらないと思っています。今後はこの方向で WebRTC のメディアチャネルは進んでいくでしょう。今は Firefox しか実装していませんが、Chrome も実装が進んでいくでしょう。

クライアント視点で見ればとてもシンプルになります。サーバ視点は忘れましょう。

Multistream ではシグナリングの考え方が少し変わります。今まではシグナリングをそれぞれのタイミングで最初だけ実行していれば良かったわけですが、今後は更新の OFFER/ANSWER が必要になるのです。

ただし、SFU を実装する場合はシグナリングサーバも込みで実装しなければなりません。そのため Multistream といってもまぁ結局やること結構増えて複雑になったなというツライ思いをするだけです。

WebRTC 界隈は覚えることが多いとお嘆きの皆様、動画や音声をリアルタイムに何かするなんてそんなもんです。元々面倒くさいのです。あきらめましょう。

Written by

Erlang/OTP / 時雨堂 / WebRTC / E2EE

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store