WebRTCを実現するためにSTUNだけでなくTURNも必要な理由

WEBベースの技術で音声・ビデオチャットを実現できるWebRTCが最近注目を集めています。

このWebRTCを使うことによって、音声技術の知識が熟知していなくても、比較的容易に音声・映像サービスを提供できるようになるからです。
また、WebRTCを使うとブラウザー上で音声・映像サービスを実現できます。

そこで、今回はWebRTCの隠れ仕事人のSTUNとTURNと話を簡単に説明してきます。

■WebRTCのアーキテクチャとは？

WebRTCは制御信号、音声信号を基本的には別の経路で通信を行います。
制御信号はクライアントーサーバー型、一方音声信号はP2Pで通信するところが興味深いところです。

音声信号をP2Pにすることにより、遅延がなく且つサーバーへの処理も軽減し音声サービスを実現できるわけです。

ところで、どのようにP2Pで音声信号を渡せるのでしょうか？NATがお互いある環境では不可能なような気がしませんか？

■STUNとは？

そこで登場するのはSTUNです。STUNはクライアントにおけるグローバルIPアドレスとポー番号を知る仕掛けです。

グローバルIPアドレス上にSTUNサーバを立て、クライアントとSTUNサーバが通信（通常はUDP）を使うことで、先ほどの情報をクライアントが知ることができます。

このあと、制御信号を使ってお互いのグローバルIPアドレスとポート番号をタイミング合わせて通信すると、なんと直接端末（あるいはブラウザー間）でUDPの信号が通ります。これをUDPホールパンチングと呼びます。

なんとも不思議な現象かもしれませんが、UDPホールパンチングの解説は下記のリンクをご覧ください。

P2Pとファイアウォール

※ちなみにTCPホールパンチングというTCPをP2Pで直接行う技術もありますが、ここでは触れません。

■TURNとは？

それでは、STUNがあれば音声サービスは必ずP2Pで実現できるのでしょうか？答えはNOです。それは、あるNATの組み合わせだと、どうしてもUDPホールパンチングでは通らないケースがあるのです。

詳しく言うと、Symmetric NAT同士あるいはSymmetric NAT-Port restrictedcone NATの組み合わせの場合、ほとんどのケースでUDPホールパンチングができません。

そのため、TURNというリレーサーバを使って、UDPホールパンチングを使えない場合の音声信号中継処理を行います。一般的にトラヒックの１〜２割はTURNを使うことになるといわれています。

NAT種別の解説は以下の資料を見てください。

ISPのNATには何が求められるか？

■ICEとは？

最後にICEです。STUNに始まり、UDPホールパンチング、TURNまでの一連の音声信号を経路確定するプロトコルがICEです。

■プロトコルの仕様について

P2PにおけるNAT越えの仕様は下記にまとめていますので、ご興味のある方は是非ご覧ください。

NAT技術者にお勧めするRFCとドラフト