定義
WebRTCとは、ブラウザーやアプリが、デバイス間で直接、リアルタイムの音声、映像、データを送れるようにする、Web標準とプロトコルの集まりです。暗号化、ネットワークの越え方、メディアの転送を扱います。
WebRTCの仕組み
WebRTCは、2つの仕様群でできています。W3CのJavaScript APIと、IETFのプロトコル群です。後者の概要はRFC 8825にまとまっています。この2つがそろうと、Webページからマイクの音声を取得し、接続を確立して、その接続で音声を送れます。
接続の確立には、3つの要素が関わります。シグナリングは、双方がオファーとアンサーを交換する手順です。WebRTCはこれをアプリケーションに任せているので、アプリごとに独自のサーバーを使います。ICEは、家庭用ルーターやファイアウォールを越える場合も含めて、双方の間のネットワーク経路を見つけます。直接の経路がふさがれているときは、STUNやTURNと呼ばれる補助サーバーを使います。そのあとメディアは、UDP上をDTLSとSRTPで暗号化されて流れ、Opusで符号化された音声を運びます。RFC 7874は、WebRTCのエンドポイントがOpusとG.711に対応することを求めています。
ブラウザーは、音声に重要な機能も備えています。エコーキャンセル、ノイズ抑制、自動ゲイン制御で、マイクの音声に対して、送信の前に適用されます。パケット損失やジッターへの適応も、アプリケーション側で何もしなくても、ブラウザーが行います。
音声エージェントにとって重要な理由
音声エージェントが発信者に届く経路は、2つあります。電話の通話は、PSTNとSIPトランクを通って届き、狭帯域の電話の音声になります。WebサイトやモバイルアプリからはWebRTCが使え、広帯域の音声のまま届けられるので、認識の面で有利で、音もよくなります。
代わりに、運用の負担が増えます。WebRTCはUDP上で動き、パケットが失われても待たずに回復するため、低い遅延に向いています。ただし、シグナリングと、多くの場合TURNサーバーが必要で、費用がかかり、構成要素も増えます。WebSocketはTCP上で音声を運びます。作りは簡単ですが、パケットが失われると止まることがあります。違いはガイドで詳しく比較しています。
アプリの中で動く音声エージェントは、電話番号も受け取りません。そのため、発信者番号通知や番号によるルーティングは当てはまらず、代わりにアプリがユーザーを識別します。
例
説明用の設定です。サポートページに「お問い合わせ」ボタンがあります。クリックするとマイクの許可を求め、エージェントのサーバーへのWebRTC接続を開いて、48 kHzのOpus音声を双方向に流します。同じエージェントが、会社の電話番号にも、SIPトランク経由の8 kHzで応答します。