音声技術の基礎｜第16回
ブラウザーで電話ができる仕組みには、マイクへのアクセスだけでなく、通信相手への経路を見つける処理や音声の暗号化が含まれます。WebRTCでよく登場するICE・STUN・TURN・SRTPを、それぞれ何を解決する技術なのかという視点で整理します。
1. 接続情報の交換と音声伝送を分ける
WebRTCのアプリケーションは、相手との接続に必要な情報をシグナリングの仕組みで交換します。WebRTCがすべてのサービスで同じシグナリング方式を指定しているわけではありません。WebSocketなどを使う構成もあります。
ページを表示でき、ログインできても、音声の通信が成立するとは限りません。マイクの許可、通信候補の交換、経路の確認、暗号化通信、音声の再生を段階ごとに見る必要があります。
2. ICEは使える経路を確認する手順
ICEは接続候補を集め、相手との間で疎通を確認し、使用する候補ペアを選ぶ仕組みです。候補には端末自身のアドレス、外側から見えるアドレス、中継サーバーのアドレスなどがあります。
候補が収集されたことと、実際に接続に使われたことは別です。トラブル調査では候補一覧だけでなく、選択されたペアとその状態を確認します。
3. STUNは外側から見える情報などを扱う
STUNは、NATの外側から見えるアドレス・ポートの確認や、ICEの疎通確認などに使われます。STUNサーバーを設定すれば、どのようなネットワークでも直接通信できるという意味ではありません。
NATやファイアウォールの条件によって、直接の経路が使えないことがあります。STUNは通常の音声を中継するためのサーバーではなく、TURNとの役割を混同しないことが大切です。
4. TURNはメディアの中継経路を提供する
TURNでは、中継用のアドレスを確保し、その経路を通じてデータをやり取りできます。直接通信できない場合や、構成上中継を使う方針の場合に利用されます。
中継を使うと経路やサーバーの負荷が変わるため、配置、容量、到達性を設計します。TURNを通ったこと自体が異常ではありません。また、UDPが使えない環境の代替経路は実装や構成によるため、採用サービスの要件と実測で確認します。
接続後に音が届かない場合は、片通話・無音の切り分けを参考に、方向ごとの経路を確認します。
5. SRTPは音声の保護を担う
SRTPはRTPに対して暗号化や認証、再送攻撃への保護を提供する仕組みです。WebRTCではDTLS-SRTPなど、鍵の確立を含む仕組みと組み合わせます。音声が暗号化されることと、通信経路が直接であることは別の話です。
通信を保護しても、遅延や損失がなくなるわけではありません。逆にパケットを取得して音声をそのまま聞けなくても、端末が提供する受信統計や音声の状態を使って調査できます。
6. 接続後に確認する項目
- マイク・出力先・ブラウザー権限を確認する。
- ICEの状態と選択された候補ペアを記録する。
- 直接経路か中継経路か、使用トランスポートを確認する。
- 送受信パケット、損失、ジッター、補償の推移を見る。
ブラウザーが音声を受信していても、出力先や再生状態の問題で聞こえない場合があります。接続確立と実際の双方向会話を別々に確認し、経路が変わった時刻も残してください。
取得した値を比較する際は、WebRTC統計の方向・単位・時間の読み方で観測条件をそろえてください。
端末や接続環境の情報を調査に使う方法は、担当者環境を可視化するResolveAXの考え方で紹介しています。
参考規格・資料
端末・接続環境・通話時刻と症状から観測範囲を整理する際は、ResolveAXによるエージェント環境の品質分析をご覧ください。担当者環境の通話品質調査を相談するから、自社の構成に合わせた確認範囲をご相談いただけます。