WebRTC研修

2
本スライドは、NTTソフトウェア社内技術者育成研修（ソフト道場研修）テキストです。
【著作権・免責事項】
• 本セミナーコースの内容、本資料のすべての著作権は、NTTソフトウェア株式会社に帰属します。
• 無断での本資料の複写、複製、再利用、転載、転用を禁じます。
• 本資料と演習等で利用するすべての教材は、NTTソフトウェア株式会社からの保証なしに提供されます。
• 本書に記載されている会社名および製品名は、一般に各社の商標または登録商標です。
WebRTC研修 Copyright© 2016 NTT Software Corporation

3
目次(1/2)
1 WebRTC概説
1.1 WebRTCとは
1.2 WebRTCの特徴
1.3 対応ブラウザ、プラットフォーム
2 IP電話について
2.1 IP電話はそもそもどうやってつながるか？
2.2 SIP/SDP
2.3 音声コーデック(PCMU/Opus)、映像コーデック(VP8)の概要説明
2.4 P2P vs B2BUA
2.5 NAT問題
2.6 NAT越え技術(STUN,TURN,ICE)

4
目次(2/2)
3 WebRTC詳細
3.1 アーキテクチャ図
3.2 処理の流れ
3.3 WebSocket
3.4 getUserMedia
3.5 RTCPeerConnection
3.5.1 createOffer(RTCPeerConnectionのメソッド)
3.5.2 createAnswercreateOffer(RTCPeerConnectionのメソッド)
3.5.3 setLocalDescriptioncreateOffer(RTCPeerConnectionのメソッド)
3.5.4 setRemoteDescriptioncreateOffer(RTCPeerConnectionのメソッド)
3.6 SRTP
4 参考情報
4.1 DataChannelについて
4.2 画面共有について
4.3 ORTC
4.4 Stats API
4.5 sipML5 Asteriskを利用した実装例
4.6 WebRTCをサポートした当社の製品
4.7 その他有用なリンク

5
１．WebRTC概説

 １．WebRTCは「Web Real-Time Communication」の略称。「Webの世界でプラ
グインなしでリアルタイムコミュニケーションを実現するための技術」。Ｗ３Ｃ
(World Wide Web Consorthium)で規定するこの機能に関連したブラウザのＡＰＩ
をWebRTC APIと呼ぶ。（WebRTCといった場合にAPIのことを指す場合とこのＡ
ＰＩを利用して実現できる技術の総称を指す場合がある。）
 ２．これまでは、ブラウザそのものが音声通話・ビデオ通話を実現する能力はもっ
てなかった(これまではプラグインをインストール)が、プラグインなしで実現できる
 ３．上記により、ブラウザが「電話」になる！
6
1.1 WebRTCとは

7
【参考】インターネットでアクセス可能なサービス例
BizMee(Web会議) https://bizmee.net/
FaceKat http://shinydemos.com/facekat/
Skyway http://nttcom.github.io/skyway/

8
1.2 WebRTCの特徴
 クライアント側はインストールレス
 ブラウザがあればよい。（アプリケーションのインストールやブラウザへのプ
ラグインのインストールは不要）。呼処理ロジックは、サーバからJavaScript
としてダウンロードします。このため、機能追加にはサーバ側が対応すれば
よい。（クライアントの変更不要。クライアントプログラムの開発費の低減）
 オープンな仕様
 標準化予定の技術であるため、特定のベンダの製品に囲い込まれる可能
性は低い。
 番号計画は自由
 電話番号(0ABJ)がなくても、相手との接続が可能。既存の番号を利用する
ことも可能。
 SRTPサポート強固なセキュリティ
 NAT越えをサポート
 データチャネル／画面共有
 Webコンテンツとの融合
 ブラウザがあれば、主要なコミュニケーション(音声・ビデオ・チャット・プレゼ
ンス)が可能
 ネットゲームへの音声・ビデオ通信の拡張
 キネクトのような処理が可能（ビデオカメラ入力をインプットとしブラウザにダ
ウンロードしたJavaScriptで画像を処理することが可能）

9
１．使えるか使えないかはブラウザの実装次第
IE, iOSが使えないのが痛い。。
(IEについてはORTCとして実装中)
インストールが不要であるため、低リテラシーな利用者（年配の方、子供等）に
向けては、よい技術であるはずだが、動作するプラットフォームに縛りがある
のはキビシイ
２．明日うごかなくなる可能性
ブラウザのWebRTC機能は安定しているとはいえ、動きがいきなり変わります。
主には、W3C仕様の変更によりブラウザのインタフェース名が変更になる、
HTTPでうごいていたものが、HTTPSでないと動かなくなる
＃事前に開発版で先行リリースされているので、十分検証する必要有り
３．保守が案外大変
１つのブラウザだけでもバージョンにより動作が変わる。ブラウザ同士でも
実装のスピードが異なる。ブラウザの組み合わせ、バージョンの組み合わせ。。
４．WebRTCでつながる、というだけでは売れない
フリーのプラットフォームも、多く、ただWebRTCでつながります、というだけでは
売り物にならない。具体的なサービス(WebRTCを使って、どう便利になるか)まで
を求められる状況
1.2 WebRTCの特徴（マイナス面）

10
1.3 対応ブラウザ、プラットフォーム
 標準化活動
 W3C ブラウザ上のプログラミングAPIを規定 WebRTC 1.0 (Editor’s Draft)
 IETF 通信プロトコルを規定議論は継続中
 クライアント（ブラウザ）
Googleが強いリーダシップを発揮し、ブラウザ側での実装を推進しています
 Google ビデオ通信可能(Android版でも動作)
 FireFox ビデオ通信可能（Android版でも動作）
 Opera ビデオ通信可能(Android版でも動作)
 Internet Explorer ORTC(後述)として実装を開始
 Safari 実装の動きなし
注：Operaはバージョン15以降でレンダリングエンジンとしてWebKit/Blinkを採用。このため基本
的な機能がChromeと同じものとなっている。
 サーバ
 PRISM (TROPO社)
 Asterisk (Digium社) Asterisk11でサポート済み(SIP over websocket)
 SkyWay(NTT Com)
 PeerJS(OSS)
 他多数

11
２．IP電話について

12
2.1 IP電話はそもそもどうやってつながるか？
従来、固定電話などに代表されるように「電話」は専用のサーバ（電話交換機）
や専用の通信網（電話網）、専用の端末（電話機）を用いて提供される特殊なサービスで
あった。専用のものを利用するため、開発・運用コストは高かった。
（通信については過去はアナログ信号が使われていたが、ISDNによりデジタル化が
図られていたが、IPベースではなかった）
20世紀末のインターネット革命により、ＩＰ通信が普及するにつれて、電話網についても
ＩＰ化の波が到来し、「ＩＰ電話」が登場した（2002年から番号割り当て開始。0ABJ番号を
もたないVoIPサービスはそれ以前からも存在。）。
次ページに従来の電話網とＩＰ電話の一つであるNGNについて比較している。

13
http://itpro.nikkeibp.co.jp/article/COLUMN/20070123/259321/ から引用
2.1 IP電話はそもそもどうやってつながるか？（続き）

14
2.2 SIP/SDP
IP電話を実現するためのプロトコルとしてはH.323, MGCP, Megacoなど、歴史的に
様々なプロトコルが存在しているが、現在広く使われているのはIETFが策定した
SIP(Session Initiation Protocol)である（SIPは基本プロトコルの容易さ、高い拡張性
という観点で他のプロトコルよりも優れていた。現状SIPの拡張仕様は多岐にわたる
ため、これらを複数組みあわせた場合にトータルとして仕様自体は複雑となっている
場合がある）。
SIP (Session Initiation Protocol):
基本となるプロトコル仕様はRFC3261で規定される。
端末(SIP UA)のSIPネットワークへの登録(REGISTER)や他UAとの通信の確立
(INVITE)・終了(BYE)などの信号・手順を規定する。音声・映像のみならずプレゼ
ンスやIMの拡張が可能であり、他のRFCで規定が行われている。
本プロトコルはあくまでの通信(セッション)の開始・終了などを規定するのみであり、
実際の通信の内容（音声であるか映像であるか、通信コーデックや通信ポート等）
については規定しない。(この部分はSDPに記述される)
⇒WebRTCでは呼制御プロトコルは規定がないので、SIPを利用してもよいし別の
プロトコルを利用してもよい。
SDP (Session Description Protocol):
RFC4566で規定している。通信（セッション）でUA同士がやりとりする際の方式
（メディアの種類、コーデック、通信ポート番号、ＩＰアドレス等）を交換する。
⇒WebRTCでもピア間のやりとりで利用する。

15
SIPメッセージ(INVITE) RFC3261から抜粋
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
【参考】SIPメッセージの例、SDPメッセージの例
SDPメッセージ例 RFC4566から抜粋
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000

16
Alice SIPサーバ Bob
【参考】 SIPシーケンス（NAT越えや認証・セキュリティ、B2BUAなどを除いたシンプル例）
RTP
REGISTER
200 OK REGISTER
200 OK
INVITE(with SDP(Offer))
INVITE
180 Ringing
180 Ringing
200 OK (with SDP (Answer))
200 OK
ACK

17
2.3 音声コーデック(PCMA/PCMU/Opus)映像コーデック(VP8)の概要説明
ドラフトバージョンのRTCWeb仕様(IETF)では、音声について以下をサポートすることが
必須となっている。
・PCMA/PCMU(ITU-T G.711 alaw/ulaw)
非常に普及しているコーデック(特にulaw)。
・Opus (RFC 6716)
最新の音声コーデック。低遅延
・DTMF(RFC 4733)
音声信号でプッシュ信号(０～９、*, #)を送受信するフォーマット
WebRTCをサポートするブラウザ同士では、少なくとも上記のような音声コーデック
を利用した音声通信は可能である。（Chrome/FireFoxは使える）
ビデオコーデックについては、IETF91でVP8とH.264の両方を実装することと決定された。
⇒Chromeは現状、VP8のみ実装、FireFoxはVP8/H.264の両方を実装
既存の電話網の映像通信についてはH.264が利用されている場合が多いため、電話網とのビデオ
を利用した相互接続時には、FireFoxの方が有利といえる。

2.4 P2P vs B2BUA
SIPで異なるピア間で通信を行う場合に、ピア同士が直接メディアをやりとりする方式
をP2P(Peer to Peer)と呼びます。これとは対照的に、メディアパスにサーバが介在する
方式も存在します。この場合、サーバはB2BUA(Back to Back User Agent)と呼ばれる
方式で動作します。
例えば、２つのSIPのネットワークがあり、SIPプロトコルやコーデックに差分がある場合
にB2BUAで変換処理を行うことにより、端末に影響・変更を与えずに２つのピア間での
通信を実現することができます。このような使い方をする際にこのSIPサーバはSIP-GW
あるいはSBC(Session Border Controller)と呼ばれます。
18WebRTC研修 Copyright© 2016 NTT Software Corporation

19
2.5 NAT問題
SIPを利用したP2P接続では、SIPサーバを介して通話者(例．AliceとBob)同士がSDPを
使ってアドレスを交換した後に、直接メディア通信(音声/ビデオ/音声+ビデオ)を行う。
通話者同士が同一のLAN内に属していれば、互いに通信が可能であるが、NATルータが
2者間に存在していると、通信ができない（NAT問題）。

20
2.5 NAT問題（補足）
メディア接続の際にはSIP-UAはSDPに記述されたIPアドレスを使って
相手との接続を行おうとする。
ただし、通常、SIP-UAを動かしているデバイスはローカルなアドレスしか意識しないため
SDPの中にはローカルのIPアドレスを設定する(NATの外のアドレスは通常は知りようが
ないし設定しない）。

21
2.6 NAT越え技術(STUN,TURN,ICE)
192.168.1.100 192.168.1.101
SIPサーバ
NATルーター
10.10.10.1
STUNを用いてNAT越えする場合
前述の問題を回避するためには、SIP-UAがデバイスのローカルのアドレスのみでなく
NATの外のアドレスを意識してSDPに含める必要がある。このときに、利用するのがSTUN
サーバである。
NATルーター
20.20.20.1
Publicな
STUNサーバ
NATルーター
10.10.10.1
192.168.1.100
Publicな
STUNサーバ
①STUN
binding
request
NATの外の
アドレスを
教えてください。
②STUN
binding
response
NATの外の
アドレスは
10.10.10.1
ですよ。
STUNの動作原理

22
2.6 NAT越え技術(STUN,TURN,ICE) （続き）
192.168.1.100 192.168.1.101
SIPサーバ
NATルーター
10.10.10.1
TURNサーバを用いたNAT越え
前ページのSTUNサーバを利用したNAT越えは有効な解決策であるが、ある種類の構成で
はNATを越えられない場合がある。このような場合にはメディアをリレーするTURN
サーバをもちいる場合がある。ただし、TURNサーバを利用すると一般的に遅延が増加する
ことやサーバの運用費がますことに注意が必要である。
NATルーター
20.20.20.1
TURNサーバ

23
３．WebRTC詳細

24
WebRTCはHTML5で規定されるaudio要素、video要素を実現する技術の名称であり、以下の３
つの機能から成り立ちます。
①getUserMedia機能（PCローカルなカメラ、マイク、スピーカデバイスアクセス）
②PeerConnection機能（他ブラウザと①のデータをU-planeで通信する機能）
③DataChannel機能（ピア間でのセキュアなデータ通信機能)
これらの機能はWebRTCを実装するブラウザにプラグインなしで実装されます。上記の機能はブラ
ウザがAPIとして公開しており、アプリケーション部から呼び出しが可能です。C-plane処理はアプ
リケーション部で実行されます。アプリケーション部はJavaScriptとしてサーバからのダウンロード
が可能です。
Webブラウザ
(HTML5クライアント)
WebRTC
アプリケーション部
（Javascript）
プログラミング可能
Webブラウザ
WebRTC
（Javascript）
RTC-Web
サーバ
U-plane処理（ICE、SRTP）
（②PeerConnection機能）
C-plane処理（SIP over websocket他）
PCローカルのカメラ／マイクへのアクセス
（①getUserMedia機能）
データ通信機能
（③DataChannel機能）
3.1 アーキテクチャ
以降では、①②について中心にのべます。
③は参考。
APIAPI

25
以下に大まかな処理の流れを述べます（ICE処理は割愛）。
１．画面ロードあるいはボタン押下などをトリガに、getUserMediaを呼び出しローカルのカメラ・マイクへのアクセ
スを取得し、自画面に表示します。
２．PeerConnectionオブジェクトを生成し、メディア情報(Offer SDP)を作成します。ローカルSDPに本情報をセッ
トします。
３．２で作成したメディア情報(Offer SDP)をRTC-Webサーバ経由で相手に送ります。
４．Offerを受信したら、PeerConnectionを生成します。受信したSDPをリモートSDPにセットしたあとで、Answer
SDPを生成してRTC-Webサーバを使って相手に送ります。Answer SDPはローカルSDPにセットします。
５．受信したAnswerをリモートSDPにセットします。
Webブラウザ
アリス
WebRTC
（Javascript）
Webブラウザ
ボブ
WebRTC
（Javascript）
RTC-Web
サーバ
PCローカルのカメラ／マイク
へのアクセス（①getUserMedia機能）
3.2 処理の流れ
Offer Ans
wer

午後はWebRTCのサンプル構築を３つのステップ（演習１、演習２、演習３）に分けて進めます。
演習１では、SDP情報を運ぶために利用するWebSocketの仕組み（ＳＤＰはのせません。まずは
純粋なトランスポートとしての利用方法について学びます）
演習２では、ローカルメディアへのアクセス(getUserMedia)
演習３では、演習１で利用したWebSocketにSDP(Offer,Answer)をのせて実際にWebRTCの動作
を行います。
演習の予告（演習１、演習２）
26
Webブラウザ
WebRTC
（Javascript）
Webブラウザ
WebRTC
（Javascript）
RTC-Web
サーバ
PCローカルのカメラ／マイクへのアクセス
（①getUserMedia機能）
データ通信機能
（③DataChannel機能）
APIAPI
演習１の範囲
演習２の範囲 26WebRTC研修 Copyright© 2016 NTT Software Corporation

27
3.3 WebSocket
概要
HTTPを拡張したWebSocketプロトコルを用いることで、Web上での双方向通信
や高速通信を可能とするAPI。
TCPソケット通信に類似のコーディングを行うことが可能。
何ができるか？
・ブラウザ上で双方向通信を行うことができる。
例：チャット、ネットワークゲームなど
※従来のブラウザでの双方向通信の問題を解消。
- 通信するたびに不要なHTTPヘッダの付加
- サーバからの応答が返ってこないと次のデータを送信できない

28
双方向通信
Web
サーバ
チャットアプリの例
メッセージ「Hello」
メッセージ「Hello」
WebSocket開始
メッセージ「Hi」
メッセージ「Hi」
コネクション維持
3.3 WebSocket（続き）

29
・プロトコルバージョンにより仕様が異なる。
特にWebSocketドラフト版に対応しているブラウザ・サーバは
組み合わせによっては動作しない可能性がある。
※最新のバージョンは、Sec-WebSocket-Version:13 （RFC 6455）
・HTTPと異なる独自プロトコルを用いるため、WebSocketに対応した
サーバが必要
対応サーバには、Tomct 7.0、Jetty 8.0、socket.io(node.js)などが存在する。
※Server-Sent Eventsは既存のHTTPサーバが利用可能
・サーバ側コードもWebSocketに合わせた実装が必要
利用上の注意点

30
// WebSocketの初期化（localhost:8124はWebSocket配置するサーバに合わせて修正）
var ws = new WebSocket("ws://localhost:8124/");
// サーバへデータ送信
ws.send(data);
// サーバからデータ受信したときの処理
ws.onmessage = function(e) {
// e.data でサーバから受信したデータを取得可能
var res = e.data;
// 以降、任意の処理
使用例
※サーバ側のWebSocketプログラミングの説明は、本研修では省略します。
※一部抜粋
No. API 概要
１ WebSocket(URL) 接続先URLを指定してWebSocketを初期化
2 send(data) 指定されたdata（文字列、バイナリ）を送信。
3 onmessage(callback) サーバからデータ受信した際の処理を定義。
callbackに受信時の関数を指定。
4 close() サーバとの接続を切断。

31
3.4 getUserMedia
<input type="button" value="Start" onclick="start()" id="startBtn">
<script>
var startBtn = document.getElementById('startBtn');
function start() {
navigator.getUserMedia({audio:true, video:true}, gotStream, logError);
startBtn.disabled = true;
}
function gotStream(stream) {
stream.onended = function () {
startBtn.disabled = false;
};
}
function logError(error) {
log(error.name + ": " + error.message);
}
</script>
使用例
No. API 概要
１ getUserMedia(MediaStreamConstraints
constraints,
NavigatorUserMediaSuccessCallback
successCallback,
NavigatorUserMediaErrorCallback
errorCallback)
ブラウザが音声入力デバイス(マイク)、映像入力
デバイス(カメラ)にアクセスし、そこから取得でき
るストリーム。
第１引数：音声、映像の指定
第２引数：アクセス成功時のcallback
第３引数：アクセス失敗時のcallback

32
セキュリティの観点から、最新のChromeではhttpsスキームでダウンロードした
JavaScriptからでなければgetUserMediaを呼び出せなくなっています。
（不正なサイトにアクセスし、そこからダウンロードしたJavaScriptが、カメラ・マイクに
アクセスできるようになると、セキュリティ上、問題となる可能性があります。）
今回の演習も元々、HTTPSで動作するように作っていたため、JavaScript含めて、
大きく書き直しています。
3.4 getUserMedia（続き）

33
3.5 RTCPeerConnection
RTCPeerConnectionでは複数のメソッドを定義しているが、この中で特に重要なものについて本
研修（講義および演習）で扱う。
No. API 概要
1 RTCPeerConnection オブジェクトコンストラクタ
2 createOffer Offerの生成
3 createAnswer Answerの生成
4 setLocalDescription ローカルSDPの設定
5 setRemoteDescription リモートSDPの設定
6 updateIce ICE/TURNサーバ情報の更新
7 addIceCandidate 相手から通知されたICE candidateをブラウザに通知
8 getConfiguration PeerConnectionの設定を取得
9 getLocalStreams PeerConnectionを使って相手に送っているストリーム(映像・
音声)を取得
10 getRemoteStreams PeerConnectionを使って相手に送っているストリーム(映像・
音声)を取得
11 getStreamById IDで指定されたストリームを取得

34
No. API 概要
12 addStream 指定したストリームをPeerConnectionに追加
（典型的な例はgetUserMediaで取得したストリームを
PeerConnectionに追加する）
13 removeStream 指定したストリームをPeerConnectionから削除する
14 close 相手とのP2P通信を終了する
15 localDescription (読み取り専用)ローカルのSDP情報
16 remoteDescription (読み取り専用)リモートのSDP情報
17 signalingState (読み取り専用)通話状態
18 iceGatheringState (読み取り専用)ICEの情報収集状態
19 iceConnectionState (読み取り専用)ICEの接続状態
20 onnegotiationneeded
21 onicecandidate ICE candidateが取得できた場合のcallback
22 onsignalingstatechange 通話状態が変化した場合のcallback
3.5 RTCPeerConnection（続き）

35
No. API 概要
23 onaddstream リモートピアがストリームを追加した場合のcallback
24 onremovestream リモートピアがストリームを削除した場合のcallback
25 oniceconnectionstatechange ICE状態が変化した場合のcallback

36
No. API 概要
１ RTCPeerConnection(RTCConfiguration
pc_config)
PeerConnectionオブジェクトのコンストラクタ
第１引数：RTC設定（ICE/TURNサーバの指定、
ICEトランスポートの指定、ピア名の指定）

37
No. API 概要
１ createOffer(RTCSessionDescriptionCallback
successCallback,
RTCPeerConnectionErrorCallback
failureCallback, RTCOfferOptions options)
Offer SDPの生成を行う
第１引数：成功時のコールバック
第２引数：失敗時のコールバック
第３引数：Offer生成時のオプション指定（音声
受信、ビデオ受信の有無など）
3.5.1 createOffer （RTCPeerConnectionのメソッド）

38
No. API 概要
１ createAnswer
(RTCSessionDescriptionCallback
successCallback,
failureCallback);
Answer SDPの生成を行う。
第１引数：アクセス成功時のcallback
第２引数：アクセス失敗時のcallback
3.5.2 createAnswer （RTCPeerConnectionのメソッド）

39
No. API 概要
１ setLocalDescription
(RTCSessionDescription description,
VoidFunction successCallback,
failureCallback)
ブラウザに自マシン(すなわちローカル)のSDP
をセットする。
第１引数：セットするSDP
典型的な例では発信者はcreateOfferで生成し
たSDPを本APIで設定し、受信者は
createAnswerで生成したSDPを本APIで設定
する
3.5.3 setLocalDescription （RTCPeerConnectionのメソッド）

40
No. API 概要
１ setRemoteDescription
(RTCSessionDescription description,
VoidFunction successCallback,
failureCallback);
ブラウザに相手マシン(すなわちリモート)の
SDPをセットする。
第１引数：セットするSDP
典型的な例では発信者は相手が
createAnswerで生成して送ってきたSDPを本
APIで設定し、受信者は相手がcreateOfferで
生成して送ってきたSDPを本APIで設定する
3.5.4 setRemoteDescription （RTCPeerConnectionのメソッド）

41
【参考】処理の流れ（発信者、受信者 APIの呼び出し方の大まかな流れ）
発信者受信者
１．webSocket確立１．webSocket確立
Webソケットサーバ
２．ユーザからの発呼トリガ
３．PeerConnectionオブジェクト
生成
４．getUserMedia
５．addStream()
６．createOffer()
７．setLocalDescription
８．SDP Offerを相手に送信２．PeerConnectionオブジェクト生成
３．setRemoteDescription
４．getUserMedia
５．addStream()
６．createAnswer()
７．setLocalDescription
８．SDP Answerを相手に送信９．setRemoteDescription
注：順序は例。一部前後してもよいWebRTC研修 Copyright© 2016 NTT Software Corporation

42
【参考】 APIに関する注記
今回の演習ではChromeを利用します。
getUserMedia, RTCPeerConnection利用時には以下のベンダプレフィックスをつけた
形で呼び出しを行ってください。
getUserMedia -> navigator.webkitGetUserMedia
RTCPeerConnection -> new webkitRTCPeerConnection

43
3.6 SRTP
WebRTCでは従来の電話網（あるいはＩＰ電話網）とは異なり、RTPで運ばれる
メディアデータ（音声orビデオ）がインターネット上を流れる可能性がある。このため
RTPについてセキュリティを高めるためにSRTP(Secure RTP)を利用することが
必須となっている。
（G.711 ulawなどの代表的なコーデックでエンコードされたRTPパケットは暗号化
なしで送ると盗聴された場合に、容易に通話内容を再生することが可能となっている）
SRTPでは、セッション開始時にピア間で交換した共通鍵を利用して、
音声データの暗号化等を行う。鍵交換の方式にはDTLS(UDP用のTLS。メディアパスを
利用して鍵交換)を利用する。

44
４．参考情報

45
4.1 DataChannelについて
WebRTCでは音声・ビデオ以外の汎用的なデータについてもセキュアに2者間で
通信する仕組みが用意されています。これをWebRTCではData channelと呼んでいます。
Data channelはSCTP(Stream Control Transmission Protocol)を利用しているため
順序保証／到達確認を可能にしています。また、通信はDTLSを利用して暗号化されるため
セキュアな通信が保証されます。Data channelによる通信は音声・ビデオ通信とは独立して
いるため、どちらか一方だけ利用することも両方を使うことも可能となっています。
192.168.1.100 192.168.1.101
RTCWebサーバ
Data channel機能と音声・ビデオ通信機能の関係
音声・ビデオ通信
データ通信

46
4.2 画面共有
現状、Chrome/FireFoxでは、カメラ・マイクデバイス以外に、デスクトップや特定の
アプリケーション画面、ブラウザのタブを、他のブラウザと共有することが可能となって
います。
注１）Chromeの場合には、Chrome Extensionをインストールする必要がある
（以前は、インストール無しで実行可能であったが、セキュリティ的によくないため、
現状のような仕組みとなっている）
FireFoxの場合には、Nightly版で開発フラグをたてれば動く
動作原理としては、ビデオ画面のWebRTCと同様であり、カメラからの入力映像のかわり
にＰＣ上の画面をビデオとして相手に送ります。
このため、例えばリモートサポートのような「相手のＰＣの遠隔操作(支援)」的なものは
これ単体ではできません。
＃それでも特定の用途には非常に有用だと考えます。

47
4.3 ORTCについて
ORTC (Object RTC)という新しいAPI仕様がW3Cで議論されています。
ORTC特徴：
・SDPを直接操作しなくてよくなる（SDPの理解はWebディベロッパには難解）
・メディア操作をAPIを介して提供する
・Internet Explorerで実装される予定
・既存のWebRTCの上位互換APIとして共存する可能性がある

48
4.4 Stats APIについて
WebRTCの統計情報について取得するAPIとしてStats API(Statistics API)
がW3Cで議論されています。（一部ブラウザでは実装済み）
Identifiers for WebRTC's Statistics API(Working Draft)
http://www.w3.org/TR/webrtc-stats/
⇒インターネット上で通信することが前提であるWebRTCでメディア情報やNAT超え(ICE)
の統計情報が取得できる。
パケットロス、遅延、ジッタなどの統計情報がブラウザ上で取得できるため、たとえば
映像品質が悪い場合に自動的に音声のみに切り替えを行う等の処理が期待できる

WebRTCでリアルタイム通信を実現できることにより、WebRTCをサポートしたブラウザとSIPクライ
アント間での相互接続の実現性も検討されている。
以下に、WebRTCサーバを拡張する場合（①）、ブラウザベースのSIPクライアントを利用する場合
（②）のアーキテクチャを示す。
②で示したブラウザベースのSIPクライアントとして、オープンソースで公開されているのが、
sipML5である。
Web
SIP/IMS Network
SIP
クライアント
RTC-Web
サーバ
SIP
拡張
ROAP over
HTTP、他
Web
SIP/IMS Network
SIP
クライアント
SIPsipML5
サーバ
SIP over
WebSocket
Web
ブラウザ
WebRTC
Web
ブラウザ
WebRTC
sipクライアント
WebRTC
サーバの拡張
ブラウザベースの
SIPクライアント
①
②
sipML5
SIP
サーバ
SIP
SIP
SIP
サーバ
SIP
4.5 sipML5 Asteriskに関する解説（SIPとWebRTCの相互接続実現方法）

50
sipML5とは、Doubango Telecomが2012年5月に発表したブラウザベースのSIPクライアントである。
WebRTCをサポートしているHTML5仕様のブラウザにsipML5を導入することで、SIP/IMSネット
ワークに接続しているクライアントとの音声/ビデオ通信、インスタントメッセージング等をブラウザ上
で動作させることが可能となる。
Web
SIP/IMS Network
SIP
クライアント
sipML5
サーバ
SIP over
WebSocket
Webブラウザ
WebRTC
Javascript SIP
Javascript SDP
SIP Proxy
sipML5
※動作させるためには、
webrtc2sip（Doubango
プロダクト）が必要
（詳細後述）
ブラウザ-SIP端末間で音声/ビデオ
通信やインスタントメッセージング等
のコミュニケーションが可能
SIP
SIP
サーバ
SIP
サポートされる機能
・Audio / Video call
・Instant messaging
・Presence
・Call Hold / Resume
・Explicit Call transfer
・Multi-line and multi-
account
・Dual-tone multi-
frequency signaling
(DTMF) using SIP INFO
4.5 sipML5 Asteriskに関する解説（sipML5とは）

【参考】 sipML5の動作（呼確立シーケンス） - アーキテクチャ②に対応
51
Chrome
(Alice)
SipML5
server
(webrtc2sip
)
SIPクライアン
ト(Carry)
1. HTTP GET
3. REGISTER
0. JavaScript download（SIPロジック）
SIP server
2. 101 Response (upgrade to SIP)
4. REGISTER
6. 200 OK
5. 200 OK
7. INVITE
8. INVITE
9. INVITE
10. INVITE
SRTP
通常のSIP IVITEシーケンス
＋U-Plane処理（ICEのConnectivity check含む）
サーバとのサブプロトコルネゴシェーション
(S)RTP

52
Asteriskとは米Digium社が開発したオープンソースのPBXである。
SIP, IAX, H.323など複数の呼処理プロトコルに対応している。
Asterisk バージョン11からSIP over websocketをサポートすることによりwebRTC対応のブラウザを
端末として利用することを可能にしている。
4.5 sipML5 Asteriskに関する解説（Asteriskとは）

53
Chrome
(Alice)
Asterisk
SIPクライアン
ト(Carry)
1. HTTP GET
3. REGISTER
2. 101 Response (upgrade to SIP)
4. 200 OK
5. INVITE
10. INVITE
SRTP
通常のSIP IVITEシーケンス
＋U-Plane処理（ICEのConnectivity check含む）
サーバとのサブプロトコルネゴシェーション
(S)RTP
【参考】 sipML5の動作（呼確立シーケンス） - Asteriskを利用した場合

54
4.6 WebRTCをサポートした当社の製品
弊社でもAsteriskをベースとしたWebRTC製品を製造しており、NTT研究所様の
「アトリエN」施策でご利用いただいております。
https://developer.api-trial.jp/ja/apis/crossway/document
(図はNTT研究所様のHPからの抜粋)

55
http://peerconnection-video-
chat.herokuapp.com/webrtc_report/webrtc_summary.html
4.7 その他有用なリンク
http://blog.wnotes.net/blog/article/webrtc-beginning
http://tjun.org/blog/2013/12/webrtc_p2p/
WebRTCに使われるP2Pの技術
WebRTCを仕組みから実装までやってみる
WebRTC GetUserMediaとPeerConnectionについて
http://dev.w3.org/2011/webrtc/editor/archives/20140704/webrtc.html
W3C WebRTC 1.0: Real-time Communication Between Browsers

https://www.ntts.co.jp/products/soft_dojyo/index.html

WebRTC研修

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a WebRTC研修

Similar a WebRTC研修 (20)

Más de 株式会社 NTTテクノクロス

Más de 株式会社 NTTテクノクロス (7)

WebRTC研修