【ITニュース解説】WebRTC For Beginners. Part 1

WebRTC（ウェブ・アール・ティー・シー）は、ブラウザやアプリケーション間で直接通信を可能にするオープンソースの技術である。この技術を使うことで、私たちはウェブ上で特別なプラグインやフレームワークを必要とせず、音声、ビデオ、あるいは任意のデータを、互いのデバイス間で直接交換できる。これは、インターネットに接続された二つのクライアントが、間に別のサーバーを介さずに、データを直接やり取りする「ピアツーピア」という通信方式を可能にするものだ。実際に、Google Meet、Google Hangouts、Facebook Messenger、Discordなど、私たちが日常的に利用する多くのアプリケーションがWebRTCを活用して、リアルタイムなコミュニケーションを実現している。

WebRTCシステムは、主に四つの基本的な要素から構成される。それは、シグナリングサーバー、STUNサーバー、TURNサーバー、そして実際に通信を行うクライアント自身である。

シグナリングサーバーは、クライアント同士が互いの必要な情報を交換し、接続を確立するために利用されるサーバーだ。この情報交換のプロセスを「シグナリング」と呼ぶ。シグナリングは、WebSocketやXMLHttpRequestといった技術を通じて行われる。クライアントは、例えば相手のデバイスとどのように通信すれば良いかといった情報を、このシグナリングサーバーを介してやり取りする。

STUNサーバーは、Session Traversal Utilities for NATの略である。多くのデバイスは、インターネットに接続する際にNAT（Network Address Translation）と呼ばれる技術の背後にいる。これにより、デバイスはプライベートなIPアドレスを持つが、インターネット上ではパブリックなIPアドレスに変換される。STUNサーバーは、クライアントが自身のパブリックIPアドレスと、背後にあるNATの種類に関する情報を知ることを可能にする。この情報は、後にシグナリングサーバーに送信されるデータの一部として使われる。クライアントはSTUNサーバーに情報を要求し、STUNサーバーはその情報で応答し、クライアントはその情報をシグナリングサーバーに送信するという流れで機能する。

TURNサーバーは、Traversal Using Relay NATの略で、ネットワークトラフィックを中継するためのプロトコルを提供するサーバーだ。STUNサーバーだけでは、クライアント間の直接的なピアツーピア接続に必要な情報を常に提供できるわけではない。実際、全体の15〜20%程度のケースでは、STUNサーバーの情報だけでは直接接続が確立できないことがある。このような場合に登場するのがTURNサーバーである。もしピアツーピア接続が確立できない場合、TURNサーバーがクライアント間のデータの中継役となる。このとき、クライアントは直接データをやり取りするのではなく、一度データをTURNサーバーに送信し、TURNサーバーがそれを相手のクライアントに転送するという形で通信が行われる。つまり、TURNサーバーは、直接接続が困難な場合の「バックアップ」または「中継役」としての役割を担い、通信が途絶えることを防ぐ非常に重要な存在だ。

WebRTCの仕組みをより深く理解するために、クライアントがシグナリングサーバーに送信する二種類の主要なデータについて見ていこう。それらは、SDP（Session Description Protocol）とICE Candidates（アイス・キャンディデーツ）である。

SDPはセッション記述プロトコルの略で、交換したいメディアの特性を記述するためのフォーマットだ。具体的には、ビデオやオーディオのコーデックの種類、データの送信元アドレス、音声やビデオのタイミング情報など、メディアに関する詳細な設定が含まれる。これらのメディア特性は「マルチメディア通信セッション」と呼ばれ、WebRTCにおける通信の「オファー」や「セッション招待」を作成するために利用される。SDPは実際の音声やビデオデータそのものを送信するのではなく、あくまで「どのような種類のメディアを交換したいか」という情報を、シグナリングサーバーと相手のクライアントに伝えるためのものだ。このSDPデータは、STUNサーバーからではなく、クライアント自身が生成して送る。

一方、ICE Candidatesは、クライアントのインターネット接続に関する情報を持つ。ICEはInteractive Connectivity Establishmentの略である。このICE CandidateはSTUNサーバーから取得され、クライアントのIPアドレスや、相手との通信に利用可能な方法（直接ピアツーピア接続か、あるいはTURNサーバーを介した中継接続かなど）といった情報が含まれている。

これらを踏まえたシグナリングのプロセスは以下のようになる。まず、クライアントはSDP情報、つまり交換したいメディアの特性をシグナリングサーバーに送信する。次に、クライアントはSTUNサーバーに対して、自身のICE Candidate、すなわち接続情報を要求する。STUNサーバーはクライアントにICE Candidateを返送し、その情報を受け取ったクライアントは、それをシグナリングサーバーに送る。この一連のステップは、通信相手となる受信側のクライアントでも同様に行われる。

両方のクライアントがシグナリングサーバーを通じてSDPとICE Candidateの情報を交換し終えると、互いの接続情報が揃う。この情報を使って、クライアント同士はまず直接的なピアツーピア接続を試みる。もしネットワーク環境が許せば、この直接接続が確立され、データは最も効率的な形で交換される。しかし、何らかの理由で直接接続が確立できない場合には、交換されたICE Candidate情報に基づいて、TURNサーバーを経由した中継接続へと切り替わる。この場合、データは一度TURNサーバーに送られ、そこから相手のクライアントへと転送されることで、通信が維持される仕組みになっている。このように、WebRTCは複雑なネットワーク環境においても、柔軟かつ堅牢なリアルタイム通信を実現するための多角的なアプローチをとっている。