はじめに
最近、アプリでTwilio通話を実装したり、リモートワークやインサイドセールス向けのサービス開発のお話をいただくことがあったり、何かとWebRTC関連に縁があったので、GWに改めて勉強してみました。
今回は基本事項のまとめとなります。
WebRTCとは
WebRTCは、ブラウザやアプリ間で音声や映像など大容量のデジタルデータをリアルタイムに送受信する(P2P)技術で、HTMLのAPIのひとつです。
また、不特定多数の人がファイルなどを送受信することが可能な仕組みが備わっており、ZoomやGoogle Meet、Discordなどで使われています。
構成
WebRTC接続に必要な構成は以下のようになります。
Signalingサーバ
Signalingサーバは、接続を確立したいユーザ間で、通信に必要な情報(SDP, ICE candidates)を交換するのをサポートする役割を担います。
情報のやりとりには、WebSocketやXMLHttpRequestを使用することができます。
STUN(Session Traversal Utilities for NAT)サーバ
STUNサーバは、外部ネットワークから見た際の自端末のIPアドレスを返します。
NAT内にいる場合は、自端末の知っているIPアドレス(プライベートIP)とSTUNサーバの返すIPアドレス(パブリックIP)が異なるため、これによってNATの有無を判別することができます。
NATが存在する場合、P2P通信の確立にTURNサーバが必要となります。
TURNサーバ
TURNサーバは、NATが存在する場合にP2P通信をしたい端末間でデータをリレーするものです。
SDP(Session Description Protocol)
SDPは、セッションの告知や招待を目的として、マルチメディアセッションの開始に必要な情報を記述するためのフォーマットです。
端末間の差異を吸収して最適な通話設定をするために、SDPのやりとり(通信要件のすりあわせ)を行う必要があります。
ICE(Interactive Connectivity Establishment)
ICEは、STUNサーバやTURNサーバを相互で使いながら端末間で接続を行う技術です。
P2P通信を確立するには，端末間でSDPとICE candidatesの交換が必要となります。
ICE candidatesには以下が含まれます。
- IPアドレス
- プロトコル(TCP/UDP)
- ポート番号
- コンポーネント
- タイプ
- 優先度
- ファウンデーション
- ベース
など
接続フロー
接続までのフローを簡単にまとめると以下のようになります。
- WebRTC offer(Caller→Callee)
- WebRTC answer(Callee→Caller)
- ICE candidatesの交換
- 接続
参考資料