WebRTC の輻輳制御

WebRTC 上級編

ここでは輻輳はパケロスや遅延がある状況と定義することにする。

輻輳を制御する仕組みが輻輳制御、そのまま。つまり輻輳の発生を防いだり、輻輳が発生している状況から回復する仕組みと考えて貰えば良い。

ご存知の通り WebRTC では UDP を利用している。UDP では輻輳に対して考慮は一切されていない。そのため WebRTC 側で対応する必要がある。

WebRTC で輻輳制御を行うには配信側や視聴側の状況を判断が必要になる。つまり「今自分の回線が不安定なのかどうかを知る仕組み」が必要になる。UDP なので送りっぱなしなのにどうやって気付くのか?という話になるが、送る側と送られる側の連携プレーにより気付ける仕組みがある。

今回はその仕組の1つを紹介する。

ちなみに、この仕組はまだ RFC になっていないドラフトの状態だが、libwebrtc には実装されている。

読んでも凄くわかりにくいため、ざっくりと説明していくことにする。

送る RTP パケット全てに RTP 拡張を利用したシーケンス番号がふられる。この際 Payload Type や SSRC は一切考慮されない。

受け取った側はこの RTP 拡張に入っているシーケンス番号を保持しつつ、次のシーケンス番号とのタイムスタンプの差分を見ていく。

これにより、どの程度の間隔でパケットが送られてきているかを把握することができる。さらに、パケロスやまだ受け取ってないなども記録していく。

受け取った側は RTCP-RTPFB を利用してそれらのタイムスタンプの差分や、パケットが来ていないことを送信側に送る。

ちなみにこの場合のタイムスタンプは RTP 拡張の abs-send-time を利用する。

これにより送信側と受信側は現在利用しているネットワークが不安定かどうかを知ることができる。送信側は不安定であれば自分が配信しているビットレートを自主的に下げられる。配信側は RTCP-PSFB の REMB を利用して受信可能なビットレートを送信側に提案できる。

REMB は受信側が受け取れる最大ビットレートを送信側に RTCP 経由で伝える仕組みと考えてもらって良い。

今回は WebRTC の輻輳制御の仕組みの1つついて簡単に説明した。今後も簡単に説明していければと思う。

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