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ホールパンチングを使えない場合の音声信号中継処理を行います。一般的にトラヒックの1〜2割はTURNを使うことになるといわれています。
NAT種別の解説は以下の資料を見てください。
ISPのNATには何が求められるか?
■ICEとは?
最後にICEです。STUNに始まり、UDPホールパンチング、TURNまでの一連の音声信号を経路確定するプロトコルがICEです。
■プロトコルの仕様について
P2PにおけるNAT越えの仕様は下記にまとめていますので、ご興味のある方は是非ご覧ください。
NAT技術者にお勧めするRFCとドラフト