はじめに
WebRTCとは「Web Real-Time-Communication」の略で、Webブラウザを通して映像や音声データの高速リアルタイム通信を可能にした規格です。
ZOOMみたいなビデオチャットアプリを作れたりします。
WebRTC自体は一つのプロトコルというよりも、様々な技術要素を組み合わせて成り立つ集合体のようなものです。
本記事では、WebRTCを構成する技術要素と通信を確立するまでの流れを記載します。
API
WebRTCは3つのAPIが提供されている。
-
getUserMedia : ブラウザからカメラ・マイクへアクセスするためのAPI
-
RTCPeerConnection : 映像・音声を送り合うためのAPI
-
RTCDataChannel : 任意のファイルを送り合うためのAPI
プロトコル
WebRTCは様々な技術要素が組み合わされて成り立っている。
プロトコルスタックはこんな感じ。
Audio/Video(RTCPeerConnection)
映像・音声の符号化情報をパケット化するRTPを暗号化した、SRTP(Secure Real-time Transport Protocol)を使用している。
共有鍵を交換するためにDTLSの機能の一部を使用している。
DataChannel
ストリーミング向けの転送プロトコル、SCTP(Streaming Control Transmission Protocol)を使用している。
DTLS(Datagram Transport Layer Security)により暗号化されている。
STUN、TURN、ICE
通信セッションを確立する際にNAT/Firewallを越えてネゴシエーションするための一連の標準プロトコル。
STUN(Session Traversal Utilities for NAT)
自身に割り当てられたパブリックIPを知るためのプロトコル。
STUNサーバーはパブリックにアクセス可能で、Googleもパブリックなstunサーバ「stun.l.google.com:19302」を提供している。
TURN(Traversal Using Relays around NAT)
ポート範囲の制限・固定やTCPでの通信、パケットの暗号化を実現するプロトコル。
NAT/Firewallで通信が制限される場合、TURNサーバを経由してストリーミング情報を送信する。
ICE(Interactive Connectivity Establishment)
STUNとTURNを組み合わせ、通信先へ到達する経路情報を取得するためのプロトコル。
通信経路の候補となるIP/Portの組み合わせをICE Candidateと呼び、通信先と交換する。
すべてのICE Candidateが揃ってからSDP(後述)とまとめて交換する方式を「Vanilla ICE」、先にSDPだけを交換してからICE Candidateを順次交換する方式を「Trickle ICE」と呼ぶ。
その他
SDP(Session Description Protocol)
解像度、フォーマット、コーデック、暗号化などのストリーミングメディアの情報などを記述するための規格。
通信を始める側から送るSDPをoffer、通信に応答する側から送るSDPをanswerと言う。
通信の確立
WebRTCの通信を確立するには、接続先とSDP、ICE Candidateを交換しなければなりません。
この交換をシグナリングと言い、シグナリングサーバを介して行います。
が、シグナリングに関してはWebRTCで定義がないので、実装者に一任されています。
通信確立までのフロー
Vanilla ICEの場合
ICE Candidateが全てで揃うまで待ち、リストをSDPに詰めて送信します。
Trickle ICEの場合
SDPを送信後、準備できたICE Candidateを個別に送信します。
初期接続確立までの遅延を最小限にすることができます。
参考
STUN、TURN、ICE
http://www.wata-lab.meijo-u.ac.jp/file/seminar/2017/2017-Semi1-Yuma_Kamoshita.pdf