ビジネス向けのクラウド電話システムを調べたことがある方なら、「WebRTC」という言葉を一度は目にしたことがあるでしょう。しかし、それが実際にどのような技術なのかまで説明されているケースは多くありません。
WebRTCは、「ソフトウェアのインストール不要」「ブラウザから通話可能」といった機能の説明と一緒に掲載され、その先の解説が省略されがちです。単に電話をかけられればよい利用者にとっては、それでも問題ないかもしれません。
しかし、自社のオフィスWi-Fi、従業員の自宅ネットワーク、社内VPN環境でも安定して使えるのかを判断する立場であれば、話は別です。また、顧客との通話を扱うシステムにおいて、「標準で暗号化されている」という説明が具体的に何を意味するのかも理解しておく必要があります。
この記事では、WebRTCの仕組みそのものを解説します。
ブラウザ同士の通話がどのように接続されるのか、一般の固定電話や携帯電話へどのようにつながるのか、どこまで暗号化されるのか、そしてベンダーのデモ環境ではなく、実際のオフィスでどのような問題が起こりやすいのかを見ていきます。
開発者向けの技術資料ではなく、電話システムを選定・運用する担当者向けの内容ですが、説明している基本的なWebRTCの仕組みは同じです。
WebRTCとは何か
WebRTCは「Web Real-Time Communication」の略で、WebブラウザやWebRTC対応端末の間で、音声、映像、データをリアルタイムに送受信するためのオープンな技術標準です。通信は端末同士が直接行う場合もあれば、TURNサーバーやメディアサーバーを経由する場合もあります。
専用プラグイン、ダウンロード型アプリ、専用ハードウェアを必要とせず、対応ブラウザだけで通信できます。
WebRTCは、ブラウザ側のAPIを定めるW3Cと、通信に使用されるネットワークプロトコルを定めるIETFによって標準化されています。
WebRTCが登場する以前、ブラウザ上で通話を行うには、Flash、Javaアプレット、独自のブラウザプラグインなどが必要でした。
これらはすべて事前のインストールが必要で、個別にセキュリティアップデートを行う必要があり、ブラウザによって動作が異なるという問題も抱えていました。
Googleは2011年ごろにWebRTCの初期技術をオープンソース化し、その後約10年をかけて標準化が進められました。
現在では、Chrome、Firefox、Safari、Edgeといった主要ブラウザがWebRTCを標準でサポートしています。
この共通性があるため、自宅でMacを使う従業員、オフィスでWindowsノートパソコンを使う従業員、ホテルのロビーでChromebookを使う従業員でも、基本的には同じ仕組みでブラウザ電話を利用できます。
端末が変わっても、WebRTCの仕組みそのものが端末ごとに変わるわけではありません。
ただし、WebRTCが何ではないのかも正確に理解しておく必要があります。
WebRTC自体は、電話システムではありません。
会社の電話番号を管理する機能も、着信を適切な部署へ振り分ける機能も、留守番電話もありません。通話キューや内線番号という概念も、WebRTCそのものには組み込まれていません。
WebRTCが担うのは、音声、映像、データを、さまざまなインターネット環境を越えてリアルタイムかつ暗号化して送受信するための通信機能です。
ブラウザ電話を電話システムとして成立させる電話番号、着信ルール、通話履歴、留守番電話などの機能は、WebRTCの上にプラットフォーム事業者が構築しています。
WebRTC自体が提供している機能ではありません。
電話番号、回線、ルーティングなどを含むシステム全体の仕組みについては、「クラウドPBXとは」もあわせてご覧ください。
WebRTC通話を成立させる3つの処理
画面上では単純に見えるWebRTC通話でも、接続が成立するまでには、主に3つの技術的な処理が順番に行われます。このうち、シグナリングはWebRTC自体が提供する機能ではなく、WebRTCを利用するアプリケーションや電話サービス側が実装します。
1. 接続準備を行うシグナリング
これまで通信したことのない2台の端末が、お互いにどの音声・映像形式へ対応しているのか、ネットワーク上でどのように接続できる可能性があるのかといった基本情報を交換します。
2. 通信経路を探す接続処理
情報交換が完了したら、2台の端末間で実際に使用できるインターネット上の経路を探します。
自宅やオフィスのネットワーク構成によっては、端末同士を直接接続できないため、見た目以上に複雑な処理が必要です。
3. 音声や映像を安全に伝送する処理
通信経路が見つかったら、その経路を使って暗号化された音声や映像をリアルタイムで送信します。
通話中にネットワークが混雑した場合には、利用しているブラウザやサービスが、ネットワーク状況に応じて音質や映像品質を調整します。
これらの処理は、WebRTCとその周辺システムを構成する異なる技術によって担当されています。
この役割分担を理解すると、WebRTC通話がどのように動くのかだけでなく、なぜ通話がつながらないことがあるのかも理解しやすくなります。
社員が個人の携帯番号を使って顧客対応している場合は、PCソフトフォンを検討する前にプライベート番号をビジネスに使うリスクも確認しておきましょう。
処理1：2つの端末はどのように接続情報を交換するのか
シグナリングとは、音声の送信が始まる前に、2つのWebRTC対応端末が通話に必要な設定情報を交換する処理です。
具体的には、双方が利用できるコーデック、映像の有無、次の接続処理でICEが必要とするネットワーク情報などを交換します。
ここで意外に思われることがあります。
WebRTCの標準仕様では、シグナリングの具体的な方法が定められていません。
どのように情報を交換するかは、WebRTCを利用するアプリケーション側に任されています。
実際の電話システムでは、この部分をクラウド電話サービスの提供事業者が構築し、管理しています。
通常は、双方の端末がシグナリングサーバーへ接続し、通話設定に必要な情報を交換します。シグナリングと音声・映像の通信経路は別々に構成できますが、通話開始後も、保留、転送、通話終了、接続経路の再確立などの制御にシグナリングが使われる場合があります。
シグナリングを含む通話制御基盤は、単に端末間の接続情報を交換するだけではありません。
電話システムとしての重要な処理も、提供事業者が構築するアプリケーションや通話制御プラットフォームで行われます。
例えば、会社の代表番号への着信を営業チームのブラウザ電話へ特定の順番で鳴らす、4回呼び出した後に留守番電話へ転送する、営業時間外には別のルールで着信を振り分けるといった処理です。
これらはWebRTCの機能ではありません。
WebRTCの周囲に電話サービス事業者が構築したプラットフォーム側の機能です。
処理2：ブラウザ通話は異なるネットワーク間でどのように経路を見つけるのか
ICEは「Interactive Connectivity Establishment」の略で、直接お互いを認識できない2台の端末間で、通信可能なネットワーク経路を探すための仕組みです。
実際のWebRTC通話で発生する接続問題の多くは、この部分に関係しています。
専門的な設定を行わない担当者でも、基本的なWebRTCの仕組みとして理解しておく価値があります。
企業や家庭のネットワークに接続されている端末の多くは、NATと呼ばれる仕組みを使用するルーターの内側にあります。
NATは「Network Address Translation」の略で、ネットワーク内で使用するプライベートIPアドレスと、インターネット側のIPアドレスを変換します。
そのため、ノートパソコンには「192.168.1.14」のようなプライベートIPアドレスが割り当てられていても、外部との通信ではルーターのインターネット側のアドレスが使用されます。
このプライベートIPアドレスは、そのネットワークの外側から直接使用することはできません。
異なるネットワーク上にある2つの端末が、それぞれ自分のプライベートIPアドレスしか把握していない場合、その情報だけでは相手を見つけて直接接続できません。
従来の電話における発信音のように、自動的に相手へ接続してくれる単純な仕組みではないのです。
そのため、各端末は、自分へ到達できる可能性のある接続候補を複数収集し、実際に通信できる組み合わせを確認します。
同一ネットワーク内での直接接続
双方の端末が同じネットワーク内にある場合は、ローカルネットワーク上で直接接続できることがあります。
ただし、社外の顧客や離れた拠点とのビジネス通話では、双方が同じネットワークにいるケースは多くありません。
STUNを利用した接続
STUNは「Session Traversal Utilities for NAT」の略です。
STUNサーバーは、端末が自分のルーターの外側からどのようなIPアドレスやポートとして見えているのかを確認するために使われます。
この情報を交換することで、多くの家庭用・オフィス用ネットワークでは、中継サーバーを使わずに端末間の通信経路を確立できます。
ただし、接続できるかどうかは、ネットワーク構成、ファイアウォール、VPN、携帯電話事業者の設定などによって異なります。
STUNサーバーが通話中の音声を中継し続けるわけではありません。主な役割は、双方が直接接続するために必要な外部アドレス情報を確認することです。
TURNサーバーを経由した接続
TURNは「Traversal Using Relays around NAT」の略です。
STUNだけでは接続できない場合に使用される中継方式です。
厳格な企業ファイアウォール、一部の携帯電話事業者のネットワーク、大企業で使用されることがあるシンメトリックNATなどでは、端末間の直接接続が成立しない場合があります。
その場合、TURNサーバーが双方の間に入り、通話中の通信パケットを中継します。
TURNは、端末間の直接接続が難しい環境で通信経路を確保するための重要なフォールバックです。
ただし、TURNを利用すれば必ず接続できるわけではありません。ネットワークによる通信の遮断、設定不備、認証エラー、サーバー容量不足などがある場合は、TURNを利用しても接続できないことがあります。
TURNサーバーを経由すると通信経路が長くなるため、追加の遅延が発生することがあります。遅延の大きさは、TURNサーバーの設置場所やネットワーク状況によって異なります。
また、接続時だけでなく、通話が終了するまで、音声・映像データが提供事業者のTURNインフラを通過し続けます。
そのため、提供事業者側では十分なサーバー容量と帯域を確保する必要があります。
これは、WebRTC対応の電話サービスを選ぶ際に、特に重要なポイントです。
提供事業者がTURNインフラを運用していない、または十分な容量を用意していない場合、特定のオフィスネットワークからの通話が接続できない可能性があります。
その場合は、単に音質が低下するのではなく、通話自体を確立できないことがあります。
「デモでは問題なく動作した」という結果だけでは、自社のネットワークでも同じように動作するとは限りません。
デモ環境では、STUNだけで接続できる比較的制限の少ないネットワークが使われている可能性があるためです。
ICEが利用可能な通信経路を発見すると、その経路が実際の通話に使用されます。
接続にかかる時間は、接続候補の収集方法、ネットワーク構成、ファイアウォール、TURNの利用状況などによって異なります。
処理3：WebRTCの「標準で暗号化」とは何を意味するのか
WebRTCの暗号化は、管理者や利用者が有効にするオプション機能ではありません。
すべてのメディア通信で暗号化が必須とされており、暗号化されていない通信方式へ切り替えることはできません。
IETFのWebRTC Security ArchitectureであるRFC 8827でも、暗号化が明確に要求されています。
暗号化が追加機能として扱われることの多い従来型の電話技術と比べると、WebRTCは強いセキュリティ基盤を標準で備えているといえます。
通信経路が確立された後は、オフィスネットワーク、インターネットサービスプロバイダー、単純なTURN中継など、通信経路上にいる第三者から内容を読み取られない状態で音声や映像を送信します。
実際には、主にDTLSとSRTPという2つの仕組みが使われます。
DTLSによる鍵交換
DTLSは、銀行などのWebサイトを保護するTLSと同系統の暗号化技術を、リアルタイム通信に適した形で利用する仕組みです。
WebRTC接続の両端でハンドシェイクを行い、通話に使用するセッション鍵を確立します。
この鍵交換をシグナリングサーバーに任せる必要はありません。
また、双方は、接続設定時に交換された証明書のフィンガープリントを確認します。
これにより、通常のネットワーク経路上にいる第三者による中間者攻撃を防ぎます。
ただし、フィンガープリントはシグナリング経由で交換されるため、シグナリングサービス自体の信頼性や認証方法も重要です。
SRTPによる音声・映像の暗号化
セッション鍵が確立された後は、SRTPがその鍵を使って、通話中の音声・映像パケットを暗号化します。
ここで、特にコンプライアンスの観点から区別しておくべき点があります。
WebRTCの暗号化が保護するのは、WebRTC接続の両端を移動している通信です。
クラウドPBX、録音システム、SFU、電話網とのゲートウェイなどでWebRTC接続が終端される構成では、その設備で音声が復号、処理、録音される場合があります。
また、一般の電話番号へ発信した場合、相手の電話機までWebRTCによるエンドツーエンド暗号化が維持されるわけではありません。
保存された通話録音がどのように管理されるか、通話履歴やメタデータがどれくらいの期間保持されるか、サーバーがどの国や地域に設置されているかまでは、WebRTCの仕様では決まりません。
これらは電話サービス提供事業者の判断によって決まります。
データ所在地やGDPRなどの法規制が重要な場合は、WebRTCの暗号化とは別の項目として確認する必要があります。
WebRTCで暗号化が必須になっていることは、強力なセキュリティ基盤です。
ただし、それだけでコンプライアンス要件をすべて満たしているとは限りません。
WebRTCが音声や映像をリアルタイムで届ける仕組み
音声や映像は、RTPを暗号化したSRTPとして送信されます。
通常はUDP上で通信しますが、UDPが利用できない環境では、端末とTURNサーバー間の通信にTCPやTLSが使われることもあります。
リアルタイム通話でUDPが優先されるのは、遅れて届くデータが、届かないデータよりも問題になる場合があるためです。
音声パケットが失われた後に大幅に遅れて再送されても、そのパケットが含んでいた会話の瞬間はすでに過ぎています。
すべてのデータの再送を待つと、音声の遅延が積み重なり、会話が成立しにくくなります。
UDP自体には、失われたパケットを自動的に再送する機能がありません。
ただし、WebRTCでは、再送が間に合う可能性がある場合に、RTPレベルで失われたパケットの再送を要求することがあります。特に映像通信では、失われたデータを補うために再送が利用されます。
一方、音声は時間的な制約が厳しいため、失われたパケットを待たずに再生を続けたり、コーデック側で欠落を補ったりする場合があります。
同時に、RTCPがパケット損失、ジッター、遅延、ネットワーク状態などを継続的に報告します。
利用しているブラウザやサービスは、この情報を使って、映像の解像度や音声・映像のビットレートをネットワーク状況に合わせて調整できます。
音声や映像を変換するコーデックの仕組み
通話を開始する際、双方の端末は、どの音声・映像形式を使用するかを自動的に決定します。
この処理はシグナリング時の設定交換とあわせて行われるため、利用者がコーデックを選択する必要はありません。
音声では、OpusがWebRTCの標準的なコーデックとして広く利用されています。WebRTC対応端末には、OpusとG.711への対応が求められています。
Opusは、利用可能な帯域やネットワーク状況に応じて、一般的な音声通話から高品質な音声まで柔軟に対応できます。
ネットワーク状況が悪化した場合に、通話を直ちに切断するのではなく、使用するビットレートや音質を調整できることも特徴です。
映像では、音声よりも対応状況が分かれています。
IETFのWebRTC仕様では、相互接続性を確保するため、WebRTCの映像端末にVP8とH.264 Constrained Baselineへの対応が求められています。
H.264はハードウェアによる処理に対応した端末が多く、既存の映像会議システムとも連携しやすいという特徴があります。
VP9やAV1などの新しいコーデックは、より高い圧縮効率を持っていますが、対応状況はブラウザや端末によって異なり、処理能力を多く必要とする場合もあります。
同じインターネット接続を利用していても、古いノートパソコンと新しいノートパソコンで通話品質に差が出ることがあるのは、コーデック処理に使える端末性能も関係しています。
ブラウザ通話はどのように一般の電話番号へ接続されるのか
ゲートウェイは、WebRTCと従来の電話網の間で通信方式を変換するインフラです。
多くの電話サービスでは、SIPやSIPトランクを利用してWebRTC側の通話を公衆電話網へ接続します。ただし、具体的な接続方式は提供事業者の構成によって異なります。
多くのWebRTC解説では、この部分が省略されています。
しかし、ビジネス電話システムとして考える場合、非常に重要な仕組みです。
WebRTCだけで通信できるのは、基本的にWebRTCへ対応した端末、アプリケーション、サーバーなどの間です。
WebRTC単体では、一般の固定電話、携帯電話、WebRTCに対応していない電話システムへ直接電話をかけることはできません。
ブラウザ型ソフトフォンから見ると、利用者のブラウザはWebRTCを使ってクラウド電話サービスのプラットフォームへ接続しています。
サービス提供事業者のプラットフォームは、その通話を従来型の電話インフラへ接続し直し、外部の電話番号へ発信します。
この変換処理は利用者からは見えません。
しかし、「ブラウザから一般の電話番号へ発信できる」という機能を成立させるために欠かせない技術です。
また、WebRTC対応端末間の通信とは別のインフラとして考える必要があります。
そのため、外線通話の音質や安定性は、WebRTCが正しく動作しているかどうかだけでは決まりません。
ゲートウェイの品質や、提供事業者が接続している通信キャリアの品質も、ブラウザの外へ通話が出た後の安定性に影響します。
音声以外の通信を行うデータチャネル
WebRTCには、データチャネルと呼ばれる機能も含まれています。
データチャネルを使用すると、接続されたWebRTC対応端末間で、音声や映像以外の任意のデータを送受信できます。
通信経路によっては、端末間で直接送受信する場合もあれば、TURNサーバーを経由する場合もあります。
データチャネルにも、音声・映像と同様に暗号化が適用されます。
ビジネス通話では、通話中のチャット、ファイル転送、共同操作に必要な制御情報などに利用されることがあります。
画面共有の映像自体は、通常、音声やカメラ映像と同じメディアトラックとして送信されます。
これらのデータは、音声や映像と同じWebRTC接続を利用できるため、すべての機能に個別の通信システムを用意する必要はありません。
3人以上のグループ通話はどのように処理されるのか
これまで説明したような、2つの端末を直接接続する方法は、1対1の通話では効率的に動作します。
しかし、参加者が増えると、そのままの構成では処理が難しくなります。
完全なP2Pメッシュ方式では、各参加者の端末が、他のすべての参加者へ個別に音声・映像ストリームを送信する必要があります。
3人の完全なP2Pメッシュ通話では、方向別に数えると合計6本のメディア通信が必要になります。
参加人数が増えるほど、必要な通信量と端末の処理負荷は急激に増加します。
そのため、数人を超えるグループ通話では、通常はメディアサーバーを利用する構成へ切り替わります。
代表的な方式が、SFUと呼ばれる「Selective Forwarding Unit」です。
SFU方式では、各参加者が音声・映像ストリームをサーバーへ送信し、サーバーが必要なストリームを他の参加者へ転送します。
サービスによっては、画質や通信環境に応じて複数の映像ストリームをサーバーへ送る場合もあります。
それぞれの端末が、他のすべての端末へ個別に通信する必要はありません。
利用者から見ると、どちらの構成でも単なるグループ通話に見えます。
しかし、システム内部では、2人だけの直接通話とは大きく異なるインフラが使用されています。
「WebRTCに対応している」という説明だけでは、グループ通話の品質までは判断できません。
1対1の通話を安定して処理できるサービスでも、5人での会議になると音質や映像品質が低下する可能性があります。
ブラウザ電話の導入について詳しく知りたい方へ
WebRTCの仕組みから分かるサービス選定時の確認事項
システムが問題なく稼働した後、WebRTCの仕組みを日常的に意識する必要はありません。
しかし、仕組みを理解しておくと、契約前に提供事業者へ確認すべきポイントが明確になります。
TURNインフラについて具体的に確認する
「WebRTCに対応しています」という説明だけでは、厳格なオフィスネットワークから通話できるかどうかは分かりません。
企業ファイアウォールによって直接接続できない場合に、どのようなTURNインフラを使用するのかを確認してください。
厳格なファイアウォール環境で通話を確立できなかった場合に、どのようなフォールバックが行われるのかも重要です。
ブラウザのタブを閉じた場合の動作を確認する
WebRTC接続は、基本的にWebページやブラウザ上で動作します。
通話中にタブを閉じれば、そのページで動作していた接続は終了します。
また、ブラウザが閉じている場合や長時間バックグラウンドになっている場合の着信処理は、ブラウザ、OS、サービスの実装によって異なります。
提供事業者によっては、プッシュ通知、ブラウザ拡張機能、デスクトップアプリなどを利用して、この問題へ対応しています。
これはWebRTC自体が提供している機能ではないため、実際の動作を確認する必要があります。
「暗号化」と「コンプライアンス」を分けて確認する
通信中の暗号化が必須であることは、WebRTCの強みです。
しかし、録音データの保存方法、保存期間、データセンターの所在地は、提供事業者によって異なります。
コンプライアンスが重要な場合は、WebRTCの暗号化とは別に確認してください。
グループ通話の処理方法を確認する
会議通話を頻繁に利用する場合は、1対1の通話だけでなく、複数人での通話がどのように処理されるかを確認してください。
参加人数が増えた場合の音質、映像品質、端末負荷についてもテストする必要があります。
SIPトランクや通信キャリアとの接続について確認する
一般の電話番号へ接続する場合は、WebRTCだけでなく、SIPトランクや通信キャリアとの接続品質も影響します。
ブラウザから外部の電話網へ出た後の通話品質や安定性は、この部分のインフラにも左右されます。
サービスのデモでは省略されやすい項目ですが、外線通話が多い企業にとっては重要です。
導入前に実際のネットワークでテストする
提供事業者のデモ環境だけではなく、自社のオフィスネットワークでテストしてください。
従業員の自宅Wi-Fi、社内VPN、オフィスのファイアウォールなど、実際の利用条件を再現する必要があります。
提供事業者が管理する安定したネットワーク上で問題なく動作していても、自社環境で同じ結果になるとは限りません。
CIRCLEのインフラやセキュリティに対する考え方については、「CIRCLEが選ばれる理由」もご覧ください。
WebRTC通話に必要な帯域幅
IT担当者がネットワーク容量を計画する場合、WebRTCの音声通話は、多くの人が想像するほど大きな帯域を使用しません。
実際の通信量は、コーデック、パケット間隔、音声設定、TURNの利用、通信上のオーバーヘッドなどによって異なります。
ネットワーク容量を計画する際は、音声通話1通話・1方向あたり、数十kbpsから100kbps前後が目安になることがあります。
ただし、同時通話数が多い場合は、送信と受信の両方を含めて必要な容量を計算する必要があります。
映像通話では、必要な帯域が大きくなり、変動も増えます。
解像度、フレームレート、使用するコーデックなどによって異なりますが、参加者1人あたり500kbps程度から数Mbpsになることがあります。
一般的な音声通話では、回線速度そのものよりも、パケット損失、ジッター、遅延、Wi-Fiの不安定さが問題になることが少なくありません。
ただし、同時通話数が多い環境や、上り帯域が限られた回線では、帯域不足も問題になります。
共有VPN回線の混雑なども、音声の途切れや通話切断を引き起こす原因になります。
実際の環境でWebRTC通話が失敗する原因
実際に発生するWebRTCの問題の多くは、ブラウザそのものではなく、これまで説明したいずれかの仕組みに原因があります。
TURNが用意されていない、または容量が不足している
厳格なネットワークを利用するユーザーが、直接接続できず、通話を確立できなくなることがあります。
単に音質を下げながら接続を維持するのではなく、通話自体が始まらない可能性があります。
シグナリングサーバーに問題がある
端末間で利用可能なネットワーク経路が存在していても、2つの端末が接続設定を最後まで交換できなければ、通話は始まりません。
ブラウザタブが閉じられている、またはバックグラウンド処理に対応していない
通話中のタブを閉じると、そのページ上のWebRTC接続は終了します。
また、ブラウザやアプリが起動していない状態で着信できるかどうかは、提供事業者がプッシュ通知や補助アプリなどの仕組みを用意しているかによって異なります。
VPNやシンメトリックNATによって直接接続できない
ネットワーク構成によっては、直接接続が成立せず、TURN経由の通信が選ばれやすくなります。
その結果、追加の遅延が発生し、同時通話数に応じて提供事業者側のインフラ負荷やコストも増加します。
このような問題は、提供事業者自身のデモ環境では発生しない場合があります。
デモが、通信制限の少ない安定したネットワーク上で実施されている可能性があるためです。
問題が明らかになるのは、実際の導入段階です。
従業員の自宅Wi-Fi、社内VPN、事前にテストされていないBluetoothヘッドセットなど、現実の利用環境で初めて発生します。
効果的なパイロットテストでは、デモをそのまま信用するのではなく、こうした条件を意図的に再現する必要があります。
自社の環境で利用できるか確認したい方へ
WebRTC用語集
| 用語 | 説明 |
|---|---|
| SDP | 通話に使用するコーデック、音声・映像の種類、通信設定などのセッション情報を記述するための形式です。WebRTCでは、シグナリングを通じてSDPのオファーとアンサーを交換します。 |
| ICE | 2台の端末間で利用可能なネットワーク経路を複数確認し、実際に通信できる経路を選択する仕組みです。 |
| STUN | 端末が外部ネットワークからどのようなアドレスとして見えているかを確認するための仕組みです。 多くのNAT環境では、STUNを利用することで中継サーバーを経由せずに接続できます。 |
| TURN | 端末間の直接接続が確立できない場合に、音声、映像、データを中継するサーバーです。 ネットワークの制限やサーバー側の問題によっては、TURNを利用しても接続できない場合があります。 |
| DTLS-SRTP | WebRTCが音声・映像通信に適用する暗号化の仕組みです。 DTLSで鍵を確立し、SRTPで実際の音声・映像データを暗号化します。 |
| SFU | 複数人での通話を処理するために使用されるメディアサーバー方式です。 各参加者から受け取った音声・映像ストリームを、他の参加者へ転送します。 |
| ゲートウェイ | WebRTCと従来の電話網の間で通信方式を変換するインフラです。 ブラウザから一般の固定電話や携帯電話へ発信するために必要です。 |
WebRTCの仕組みに関するよくある質問
WebRTCを利用するためにソフトウェアをインストールする必要はありますか？
いいえ。
WebRTCは、Chrome、Firefox、Safari、Edgeなどの主要ブラウザに標準で組み込まれています。
提供事業者によっては、バックグラウンドでの着信通知などを目的として補助アプリを提供していることがあります。
ただし、これは利便性を高めるための追加機能であり、WebRTC自体の必須要件ではありません。
WebRTCから一般の電話番号へ電話をかけられますか？
提供事業者が運用するゲートウェイを経由すれば、一般の電話番号へ発信できます。
ゲートウェイがWebRTCの通信を従来の電話網へ接続します。
WebRTC単体で通信できるのは、基本的にWebRTCへ対応した端末、アプリケーション、サーバーなどの間です。
WebRTC通話は必ず暗号化されますか？
はい。
WebRTCの仕様では、音声・映像通信の暗号化が必須とされており、暗号化されていない方式へ切り替えることはできません。
ただし、暗号化が維持されるのはWebRTC接続の両端までです。
クラウドPBX、録音システム、ゲートウェイなどでWebRTC接続が終端される場合は、その設備で音声が復号・処理されることがあります。
通話録音を保存した後にどのように管理するかも、電話サービス提供事業者によって異なります。
自宅では通話できるのに、オフィスWi-Fiでは接続できないのはなぜですか？
オフィスのファイアウォール、プロキシ、VPN、DNS設定などが、ICEによる接続やTURNへの通信を制限している可能性があります。
端末間の直接接続ができない場合はTURNを利用しますが、利用可能な通信方式やポートがネットワーク側で遮断されていると、TURNを利用しても接続できないことがあります。
提供事業者側のTURN容量不足や設定不備も、原因になる可能性があります。
WebRTCの仕組みを簡単にまとめると
WebRTCを利用した通話では、まずサービス側のシグナリングによって接続情報を交換します。
次にICEが利用可能なネットワーク経路を探し、確立された経路上でWebRTCが暗号化された音声や映像をリアルタイムに送信します。
一方、会社の電話番号、着信ルール、内線、留守番電話、通話履歴、一般の電話番号との接続などは、WebRTCの機能ではありません。
これらは、WebRTCの上に電話サービス提供事業者が構築するプラットフォームによって提供されます。
この違いを理解すると、サービス提供事業者の説明を判断しやすくなります。
どこまでがWebRTCの標準機能で、どこからが提供事業者独自のインフラやシステムなのかを分けて確認できるためです。
