Twilioブログ

初心者必見!よくわかるWebRTCの仕組み

リモートワークやテレワークが一般化した昨今。社内でのミーティングや社外との打ち合わせで、ビデオ通話を繋いでおこなうWeb会議・テレビ会議を活用している方も多いのではないでしょうか。

そのようなオンライン会議に使用されているツールの多くは、「WebRTC」と呼ばれる技術によって実現しています。

今回はこのWebRTCについて、どのような仕組みで通信を実現しているのか、わかりやすく解説します。

目次

そもそもWebRTCとは?

webrtc-icatch

WebRTCは「Web Real-Time Communication」の略称で、Webブラウザ間で音声やビデオ、データなどをリアルタイムにやり取りする際に用いられる技術です。

リモートワークが一般的となってきた近年、Web会議システムやライブストリーミング・動画配信サービスなどで活用される場面が増えてきています。

WebRTCの詳細は、「WebRTCとは?リモートワークに役立つブラウザ技術を詳しく解説」の記事をご参照ください。

WebRTCの対応ブラウザ例

WebRTCは、対応しているブラウザさえあれば誰でも使えるという特徴があります。2021年10月時点では、以下のブラウザがWebRTCに対応しています。

  • Google Chrome
  • Microsoft Edge
  • Mozilla Firefox
  • Safari
  • Opera

WebRTCの仕組み

WebRTCでリアルタイム通信の実現を可能にしているのは、P2P(Peer to Peer)と呼ばれる通信方式です。ここではWebブラウザ同士が直接通信するために必要な技術であるP2Pについて解説します。

P2P方式について

P2P方式は、ネットワーク上の機器同士が直接接続・通信するための方式のひとつです。

従来のネットワーク通信では、データを提供する「サーバー」と提供されたデータを利用する「クライアント」に役割が分かれるクライアント・サーバー方式が一般的でした。

しかしこの方式では、特定のサーバーに負担が集中して問題が生じた際、すべてのクライアントに影響が及んでしまうという問題がありました。

そこでP2P方式では、機器同士が役割を持たずに直接データをやり取りするため、各クライアントに負担が分散されます。またサーバーのように重要な役割を持った機器が存在しないため、障害が発生したとしても、他の機器同士の通信に影響を与えません。

P2P通信に必要な情報

Webブラウザ同士でP2Pの通信をおこなうためには、通信相手のIPアドレスなど、接続先の情報が必要です。

ここではWebRTCでP2P通信をおこなうまでにWebブラウザ間でやり取りされる情報について、詳しく解説します。

Session Description Protocol(SDP)

Session Description Protocol(SDP)は、P2P通信のための基本情報をWebブラウザ間で共有しあうために決められた、情報交換用のプロトコルです。SDPを使って共有される情報は、大きく2つあります。

使用できる動画や音声の情報 それぞれのブラウザが扱うことのできるコーデックの情報
ネットワーク情報

それぞれのブラウザのIPアドレスやポート番号などの情報

このように、双方がお互いに接続先の情報や扱える映像や音声の情報を確認し、相互に通信するための準備をおこないます。

Interactive Connectivity Establishment(ICE)

SDPを利用してお互いのネットワーク情報がわかったら、継続して接続するための経路を見つける必要があります。Interactive Connectivity Establishment(ICE)は、通信可能な経路を確認するためのプロトコルです。

ICEはお互いのネットワーク情報を確認した後、ブラウザ同士が通信するために利用できる通信経路をピックアップします。ICEによって導き出された接続経路の候補は「ICE Candidate」と呼ばれます。

WebRTCでは通信を開始する際、ICE Candidateが見つかった順に接続を試みて、最初につながった経路を採用して通信をおこないます。

シグナリングサーバー

WebRTC単体では、通信相手の情報を取得・共有できません。そのため「シグナリングサーバー」と呼ばれるサーバーを利用して、相手のユーザー名や通信に必要な情報を取得できるようにしています。

P2P通信を実現するには?

P2Pの通信をおこなうためには、お互いにIPアドレスの情報を交換し、通信可能な接続経路を決定する必要があります。しかし異なるNAT内の端末は、相手のプライベートIPアドレスを知ることはできません。

このNATをまたぐ接続のことを「NAT越え」と呼び、P2P通信をおこなううえでの課題とされています。

NATについて

NATは、組織内ネットワークでのみ使用できる「プライベートIPアドレス」と、世界中のインターネットとつながる「グローバルIPアドレス」を変換する機能のことをいいます。

パソコンからインターネットに接続する場合、プライベートIPアドレスをグローバルIPアドレスに変換する必要があります。その役割を担う機器として挙げられるのが、自宅やオフィスで使われているルーターです。

ルーターを経由するインターネット接続の例

組織内のパソコンなど、プライベートIPアドレスを割り振られている端末は、ルーターを経由してインターネット上に出ていきます。

  1. ルーターがパソコンのIPアドレスを、自身の持つグローバルIPアドレスに変換してデータを送り出す。
  2. 接続先からルーター宛にデータが返ってくると、ルーターは接続先をパソコンのIPアドレスに変換し、データを返す。

NATを介したネットワークでは、P2P通信が難しい

つまり同一のネットワーク内にない端末同士が接続をおこなう場合、双方はルーターのグローバルIPアドレスに接続することになります。ルーターにデータが到達したとしても、その先にあるパソコンのプライベートIPアドレスまでは不明なため、インターネット上から直接パソコンに接続することはできません。

この仕組みによって、ブラウザ同士でP2P通信をおこなおうとした場合にも、インターネット上からの接続が拒否されてしまう問題が発生します。

STUNサーバーとTURNサーバー

互いのIPアドレス情報を交換しなければならない性質上、P2P通信をNATを介したネットワークで行うのは困難です。しかし現在多くのWeb会議システムに使われているWebRTCは、NAT越えを実現しています。

この技術は「STUNサーバー」と「TURNサーバー」と呼ばれる、2種類のサーバーを利用することで可能になります。

STUNサーバー

STUNサーバーは「自端末の外部ネットワークから見たIPアドレスを教えてくれる」役割を持ちます。利用者のパソコンからSTUNサーバーにアクセスすると、STUNサーバーから見たパソコンのIPアドレスとポート番号を返してくれるのです。

パソコンはSTUNサーバーから返ってきた結果から、自身がインターネットに接続する際にNATによってIPアドレスが変換されているかを判断できます。またインターネットから見たパソコン自身のIPアドレスとポート番号のセットがわかるため、P2P通信の相手に接続先情報として共有できます。

TURNサーバー

特に企業のネットワークでは、セキュリティ対策の一環としてファイアウォールが設置されているケースがほとんどです。STUNサーバーを利用して通信したい相手の情報を把握し、直接通信しようとしても、ファイアウォールによって遮断されてしまいます。ここでTURNサーバーが活躍します。

TURNサーバーはP2P通信をおこなうWebブラウザ間に入り、通信を中継する役割を持っています。

それぞれのWebブラウザは、NATを経由して通信しているつもりでTURNサーバーへ通信をおこないます。Aのブラウザからきた通信をBのブラウザに中継し、Bのブラウザから返ってきた通信をAのブラウザに返す……という処理を繰り返すのです。

このようにSTUNサーバーとTURNサーバーを組み合わせて使うことで、NATを利用したP2P通信が可能となります。

P2P通信が成立するまでの流れ

複数のWebブラウザ間で通信するためには、SDPを利用して接続するための情報交換をおこなうなどの準備が必要です。

事前に接続先の情報がわかっている場合、WebRTCのP2P通信が成立するまでの流れは次のようになります。

①ブラウザの準備

Webブラウザでカメラやマイクなどを利用する準備を整えます。

②通信の開始処理

SDPを利用して、接続先の情報を交換します。

③ICEを使って通信経路を設定

ICEの仕組みを利用して、接続相手との接続可能な経路を探します。

④P2P通信開始

相互接続する経路が確定したら、P2P通信が開始されます。

WebRTCで多拠点接続を行う方法

WebRTCでは機器同士が直接接続・通信をおこないます。そのため接続数が増えると各クライアントの通信量も比例して増加し、リアルタイムで処理することが難しくなるというデメリットがあります。

つまりP2P方式だけで通信をおこなう場合、接続可能な拠点数に限りがあるということになります。WebRTCで多拠点接続をするには、補助機能を利用する必要があるのです。

ここでは多拠点接続を実現するための、2種類の補助機能を紹介します。

SFU方式

SFU(Selective Forwarding Unit)方式は、すべての通信がサーバーを経由しておこなわれる、クライアント・サーバー方式の通信方法です。

1台のクライアントから送られた通信をSFUサーバーが受け取って、他の拠点へそのまま転送します。これによって各クライアントはSFUサーバーとだけ通信すればよいため、拠点数が増えても負担が増えることはありません。

MCU方式

MCU(Multipoint Control Unit)方式は、SFU方式と同じく、MCUサーバーがすべての通信を中継するクライアント・サーバー方式の通信方法です。

SFU方式との違いは、クライアントから受け取ったデータをそのまま転送するのではなく、合成・変換してから送る点です。これによってMCU方式では、送信元のクライアントに関わらず、すべてのクライアントが同じ方式のデータを受け取れます。

一見MCU方式の方が優れているように見えますが、データを変換する際の負荷が大きいため、利用できる設備のリソースによって適した方式は変わります。

コミュニケーションAPI「Twilio」のご紹介

Twilio(トゥイリオ)は電話やSMS、ビデオ、チャットなど世の中にあるさまざまなコミュニケーションチャネルを、WEB・モバイルアプリケーションと繋ぐクラウドコミュニケーションAPIです。

Programmable Video

TwilioではWebRTCを基盤としたアプリ開発用SDK「Programmable Video」を提供しています。

こちらを利用することで、ブラウザやアプリ上で使える高品質・高機能なリアルタイムビデオ機能を簡単に構築していただけます。またインフラ部分はあらかじめTwilioで用意しているため、ビデオ開発のみに注力していただけるのも大きな特徴です。

Programmable Videoでは、用途やニーズに合わせて、以下3つのプランから必要なものをお選びいただけます。

Group Room

最大50人までのグループ通話が可能です。またWebRTCだけではできない、オーディオとビデオの録音・録画ができます。

Peer to Peer

ブラウザ同士が直接やり取りを行います。最大10機まで接続可能です。

Video WebRTC Go

1対1のビデオアプリケーションを構築・稼働できる無料プランです。WebRTCをベースに構築できるため、ゼロから開発する手間を省くことができます。

録音・録画機能はご利用いただけませんが、気軽にProgrammable Videoを体験するのにおすすめのプランです。

Twilioのビデオ会議アプリ

またTwilioでは、上記のProgrammable Videoを活用したビデオ会議アプリをオープンソースにて公開しています。

「たった5分でビデオアプリケーションを構築・実行できる」という手軽さが魅力で、リモートワークが急速に普及した近年は特に需要が高まっています。また最近ではテキストや添付ファイルを送れるチャット機能も加わり、さらに使いやすくなりました。

Twilioのビデオ会議アプリケーションを、ぜひお客様のサービスにご活用してみてはいかがでしょうか?

まとめ

WebRTCがリアルタイムにコミュニケーションをおこなう仕組みを知ることで、ツールへの理解もより一層深まったのではないでしょうか。 

テレワークが一般的なものになり、社内コミュニケーションのあり方も変わってきています。新しいコミュニケーション方法の構築として、ぜひWebRTCの導入を検討してみてはいかがでしょうか。

Twilio 本部
Twilio 本部

KDDIウェブコミュニケーションズは、日本初のTwilioパートナーとして常に「開発者目線」を大切にしており、ブログ記事がお役に立てれば幸いでございます。

Twilioサインアップ-ブログフッターバナー

Share!!

この記事を読んだ人へのオススメ

  • お役立ち情報
  • イベント情報
  • 相談会申込
  • 導入事例