少し WebRTC を知っている人ほど WebRTC は古い技術の集合体という印象がある人が多いです。
実際 DataChannel で利用されている SCTP はかなり古くからある技術を無理やり DTLS over UDP に乗っけて、拡張したものです。SCTP そのまま使われているため古い技術をうまく使っているというのは間違いありません。
とはいえ DataChannel も QUIC に置き換わろうとしていますが、今回はその話は置いてきます。
今回は MediaChannel で利用しているプロトコルがどんな状況なのかについて書いていきます。
まとめ
WebRTC は古いプロトコルをベースにして拡張し続けていっています。古き良き時代を捨て、新しい時代に向けて積極的です。
既存のプロトコルを拡張する限界も感じており、今後は QUIC ベースで進んでいくという流れも間違いありません。
WebRTC SFU 界隈も皆 QUIC 対応を始めています、新しい技術を使いより今まで扱いづらかったものを実現しようとしています。
WebRTC は古いプロトコルの集合体ではなく、最先端技術の集合体です。
RTP とは？
RTP とはリアルタイムトランスポートプロトコルの略です。UDP ベースで音声を運ぶためのプロトコルでしたが、映像も運んでいます。
RTP プロトコルが策定されたのは 1996 年です。もう 20 年以上前のプロトコルになります。自分が初めて勉強したタイミングはいまから 5 年ほど前で SIP や SDP と組み合わせて利用する仕組みでした。
SIP とは？
SIP はセッション確立プロトコルです。セッションを開始して、変更して、終了するというのを通知するプロトコルです。とてもシンプルでかなり HTTP に似ています。
SIP でセッションをコントロールして、SDP で相手と情報交換をして、 RTP で通信をするというのがよく言われる SIP を利用した電話です。
SIP を勉強した当時は、通信の暗号化もほとんど使われておらず、ハードフォン側の独自仕様もひどく、かなり「いけてないプロトコル」というのが正直な印象です。5 年たった今もしかすると最先端の技術に追従しているのかもしれませんが、ハードウェアはそんなにすぐに買い換えないですし、おそらく今も変わらずレガシーのままなんだろうと思います。
SDP とは？
SDP はセッション記述プロトコルです。音声や映像を利用する場合「相手が理解できる技術を利用する」必要があります。そのために「自分はコレとコレとコレなら使える」「では自分はコレとコレだから、コレを使おう」というのを記述できるプロトコルです。
大変読みにくいと評判ですが、慣れの問題です。
WebRTC における RTP の利用
DTLS-SRTP による暗号化
WebRTC では音声と映像のやり取りに RTP を利用しています。ただ生のデータではなくDTLS-SRTP という技術を使っています。
実は DTLS という Datagram 用の TLS は殆ど使われてるの知らなかったのですが、 WebRTC では DataChannel でも MediaChannel でもベースの技術として利用されています。
とはいえ、 MediaChannel ではあくまで MasterSecret の共有のためだけに使われているというなんとも悲しい話ではありますが。
SRTP は 2004 に登場したとても古いプロトコルなんですが、自分が調べた当初 SRTP が利用できる安価なハードフォンはほぼなく、暗号化？なにそれというレベルだったのをとても衝撃を受けたのを覚えています。
DTLS-SRTP という暗号化方式以外は受け付けないという仕組みが WebRTC のとった強硬策です。いままで暗号化、わかってはいるけど … という弱気な立場だった SIP のハードフォンの存在を完全に無視しているのがポイントです。
SIP がどれだけいけてなかったかについてはいくらでも書けるんですが、メインはそこではないので以下の資料を読んでみてください。
RFC ドラフトの積極的採用
RFC になる前は RFC ドラフトという状態で公開され色々議論がされていき、最終的に RFC となります。
WebRTC では最終的に RFC となった機能が積まれることはかなりまれで、基本的には RFC ドラフトベースです。
つまり「動いてるんだから別にいいだろ」という強いお気持ちを感じます。
実際 WebRTC に関連する大量の RFC ドラフトがあるので、興味ある人は少し古いですがこちらをどうぞ。
RTP 拡張
RTP には RTP 拡張という機能があり、独自で RTP パケットを拡張できるような仕組みがあります。SDP で定義して合意が得られれば使っても良いことになっています。
そして WebRTC ではこの RTP 拡張をかなり積極的に採用しています。
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:12 urn:3gpp:video-orientation
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-idあまりにも採用しすぎて、そんなに拡張が使われるとは思っていなかった時代に定義された RTP 拡張が対応している 1 バイト形式と呼ばれる形式だけではなく 2 バイト形式にも対応し、さらに 1 バイトと 2 バイト形式両方に対応する RFC にも対応しました。かなり最近の話です。
a=extmap-allow-mixed という SDP 拡張まで用意し、採用しています。
SSRC レス
そして極めつけは「 SSRC とかもういらないからなくしてしまおうぜ」です。
SSRC とは Synchrozination Source の略ですごく簡単に言えば、映像や音声のソースを認識するための仕組みです。
32 ビットの数値なので、この数値だったら映像で H.264 などが判定できるようになる仕組みです。ただ最近はこの SSRC すらも不要だろうという判断で進んでいます。
SSRC はもともと SDP で交換してお互いに「自分はこの番号で送るからよろしく」というものだったのですが、最近は「適当につける」という恐ろしい仕組みが始まってきています。
そのかわりに出てきたのが RTP 拡張を利用して RTP に勝手に名前をつけられる RID という仕組みです。
SSRC なんてわかりにくいものは不要だ、 RID で自分で好きに名前をつけられるようにすべきだという主張のもと、すでに WebRTC に組み込まれています。
とはいえ、そう簡単に RTP の仕組みがうまく回ることはなく SSRC と RID を併用するべきという案を Google の人が出してたりします。
