WebRTCの多重化の現状・未来について

本記事は、2017年WebRTCアドベントカレンダー3日目の記事です。

WebRTCの通信で使われる技術の1つである、多重化について簡単に解説してみます。完全な初心者向け記事ではなく、WebRTCで使われるプロトコルについて、少しだけ勉強したことがある人向けです。

WebRTCにおける多重化とは

WebRTCの通信では、音声・映像・データなどの複数種類のメディアが、1つのトランスポートアドレス¹で送受信されます。もともとWebRTCで用いるプロトコル(たとえばRTP)は、多重化はポート番号によって実現するものが多かったのですが、複数のポートを使うとP2Pの接続成功率が落ちる・ネットワーク経路上の装置の負荷が高い、などの理由から極力、1つのトランスポートアドレスに多重化されるようになっています。

実際に、P2P通信を実施した場合に、On the wireで流れているペイロードは、以下に示すようなプロトコルが多重化されています：

• ICE
• DTLS(-SRTP)
• SRTP
• SRTCP

ここで、ちょっとした疑問として湧くのは、どのようにそれぞれのプロトコルを見分けるか？といった点です。この方法について、3つの仕様を説明します。

(現状) 見分け方

先に答えとして、RFC5764に分かりやすい説明があります。

   The process for demultiplexing a packet is as follows.  The receiver
   looks at the first byte of the packet.  If the value of this byte is
   0 or 1, then the packet is STUN.  If the value is in between 128 and
   191 (inclusive), then the packet is RTP (or RTCP, if both RTCP and
   RTP are being multiplexed over the same destination port).  If the
   value is between 20 and 63 (inclusive), the packet is DTLS. This
   process is summarized in Figure 3.

                   +----------------+
                   | 127 < B < 192 -+--> forward to RTP
                   |                |
       packet -->  |  19 < B < 64  -+--> forward to DTLS
                   |                |
                   |       B < 2   -+--> forward to STUN
                   +----------------+

    Figure 3: The DTLS-SRTP receiver's packet demultiplexing algorithm.
         Here the field B denotes the leading byte of the packet.

すなわち、WebRTCのクライアントは何らかのパケットを受け取った場合に、最初のバイトを確認します。その値が0または1であれば、それはSTUNパケットです。仮に128-191の範囲であれば、それはSRTP/SRTCPです。最後に、20-63であるならばDTLSであるという判別ロジックになります。

RFC5764からRFC7983へ

(注: このセクションは実装じゃなくて、仕様だけの話です。WebRTCのクライアントとして、かなり使われているであろう Chromium は後述するZRTP²を実装していません)

前述のRFC5764は、RFC7983でオーバーライドされています。RFC5764は、いくつかの点(たとえばZRTP/TURN Channelが考慮されていない)で仕様として不足があります。そこで、RFC7983では、さらに網羅性を考慮した判別ロジックが定義されています。

                    +----------------+
                    |        [0..3] -+--> forward to STUN
                    |                |
                    |      [16..19] -+--> forward to ZRTP
                    |                |
        packet -->  |      [20..63] -+--> forward to DTLS
                    |                |
                    |      [64..79] -+--> forward to TURN Channel
                    |                |
                    |    [128..191] -+--> forward to RTP/RTCP
                    +----------------+

前セクションの説明と同様で、パケットの1バイト目を見てどのように判別するか、について図に表現されています。(読み方は前と一緒なので割愛)

未来へ w/ QUIC

前セクションまでは、すでにRFCとしてStandards Trackに乗っているでしたが、前回のIETF 100で議論されている未来の話もあります。すなわち、見出しにあるように、QUICをHTTP/2だけではなく、もっと汎用的にWebRTCにも使った場合に、どのように判別するかという話です。

以下の図は、AVTCOREというワーキンググループで提示されている資料から1ページだけ抜粋したものです。

図から明らかなように、判別後のプロトコルにQUICが追加されています。

IETF 100ではこの資料などをベースに、実際に議論が行われているはずです。ただし、本記事執筆時点ではまだ、AVTCORE議事録がアップロードされていないので、議論の顛末(たとえば、そもそもワーキンググループで採択して議論するのかどうか)は不明です。（もし、現地/リモートで出席した方がいれば補足いただけると助かります）

まとめ

ということで本記事では、WebRTCの多重化の現状・未来について、簡単に説明しました。QUICを含む今後の議論をを詳しく知りたい場合は、IETFを追いかけるのがオススメです。

1. IPアドレスとポートの組み合わせのこと ↩

2. DTLS-SRTPがあるのに関わらず、なぜZRTPがあるのか、については
   webrtcH4cKS: ~ WebRTC and Man in the Middle Attacks が分かりやすいです ↩