WebRTC NextVersion時代のJavaScript開発

2016/2/17(Wed)@WebRTC Conference Japan 2016
仲裕介（NTTコミュニケーションズ）

名前：仲裕介（なかゆうすけ/@Tukimikage）
所属：NTTコミュニケーションズエンジニア
仕事：WebRTCプラットフォーム SkyWayの開発
Web技術者向け情報メディア HTML5 Experts.jp 運営
プライベート：WebRTC Meetup Tokyo / Japan 主催者の一人
http://webrtcjp.info/

 私達WebRTCプラットフォーマーは、自社で提供するJavaScriptライブラ
リを常に完全動作させるために、ブラウザのAPIの実装状況や標準化動
向に目を配っています。
今後注目すべきWebRTC APIの変化につ
いて、今日はお話します。

 WebRTC APIの標準化動向や各ブラウザの実装状況を
ウォッチしていますか？
 「お金出してるから（orお金出してないけど）
WebRTCプラットフォーム使ってるから大丈夫！」と
思ってませんか？

 WebRTCのアプリ開発を行う上で今や無くてはならない存在
OpenTok
tokbox
IceLINK
frozen mountain

 WebRTCのアプリ開発を行う上で今や無くてはならない存在
Skylink
Temasys
SkyWay
NTT Communications

 WebRTCアプリ開発者がこれらプラットフォームを利用するメ
リットは？
 クロスブラウザやiOS/Androidをはじめとするクロスプラットフォー
ムに対応している。
 WebRTCに必要なサーバAPIを提供してくれるため、開発者が専用サー
バの運用を行わなくて良い。
 複雑で更新頻度も高いネイティブAPIを使いやすくラップし、ブラウ
ザのアップデートにも勝手に追従してくれる。
….etc

 逆に、WebRTCアプリ開発者がこれらプラットフォームを利用す
るデメリットは？
 WebRTCはブラウザのアップデートが早いため、昨日まで動いていた
機能が今日動かない！とかザラにある。サービス復旧はプラット
フォームの対応次第という事になりかねない。
 クライアントのWebRTC実装はSDKとして隠蔽されているため、トラ
ブルシューティング時のハードルが高い。
 エンジニアのWebRTC力の低下を招く。（つまり、生でWebRTCの実
装ができなくなる）
….etc

 これ、じつはかなり恐ろしい状態・・・なぜか？
 WebRTCは、ブラウザ同士の実装差分や、端末スペック、ネットワーク環
境の違いなど様々な要因が動作に影響を与える。
 開発環境ではバッチリ動くけど、お客様のところでは動かないなんてよく
ある話。おまけに最後まで原因がわからないことも多い。
※ここで折れると「何だWebRTCって使えないじゃん！」となる・・・・
 そうならないために現場のエンジニアは、それら不測の事態に対処する必
要が出てくる。生WebRTCの実装を読み解く力（＝WebRTC力）が必要に
なる。
※解決策の１つでは
あるけど完全じゃな
い

 WebRTCのアプリ開発を行う場合、WebRTCプラットフォーム
サービスを活用すると、かなり簡単に実装できる。
 しかし、ビジネスユースでWebRTCのアプリ開発を行う場合は、
お客様の環境で期待通りの動作をさせるためのチューニングや、
万が一動かない場合のトラブルシューティングなどをきっちり対
応する必要があり、技術力を要求される。
 そのために、ブラウザの実装状況や最新の標準化動向なども忘れ
ずにウォッチしWebRTC力を維持しましょう。

 皆さんのWebRTC力を維持するために、今日は、今年かなりホッ
トになるであろう話題にフォーカス
 WebRTC 1.0 から WebRTC Next Version へのシフト
（注：JavaScriptにフォーカスします）

 WebRTCのJavaScript APIは今大きく変わろうとしている
 W3Cの標準化の現場では、WebRTC 1.0の仕様FIXに向けて様々な議論
が行われている（2016 1Qに勧告候補になるらしい）
 その先のWebRTC Next Version / NV（仮・この資料では次世代仕様を
今後そう呼ぶ）についても既に議論が活発に行われている。

 W3Cも支持を表明している Extensible Web という考え方に基づき、
今後標準化の場では、ユースケースを限定しないローレベルなAPIが
提唱されていく
 Extensible Webで何が変わる？
 課題
 ブラウザベンダやW3CがAPIを提案しそれを標準化するという、今までの手法
では、Web開発者にとって必ずしも使いやすいAPIにはならず、Web開発者が
標準化の現場で置き去りになるという問題があった。また、APIの実装や標準
化に時間がかかりすぎていたという面もあった。（事実WebRTC1.0は伸びに
伸びている…）
 解決策
 Extensible Webでは、ブラウザベンダやW3Cはユースケースをあまり限定し
ない、セキュアでローレベルなAPIをWeb開発者に提供することに注力する。
Web開発者は、自分たちが実現したいユースケースに沿って、それらのAPIを
自由に組み合わせることが可能になる。また、その結果を標準化の場に
フィードバックできる仕組みを用意する。

 WebRTCの世界では Extensible Web で具体的に何が起こるのか
 WebRTC1.0の世界（今までの世界）
 WebRTC1.0では、PeerConnectionオブジェクトが様々な機能を隠蔽してお
り、開発者はそのオブジェクトにメソッドを利用してアクセスすることで、
WebRTCの想定するユースケースを実現してきた。
→ WebRTC1.0の想定するベーシックなユースケース
＝１：１ビデオチャット

 WebRTC NVの世界（これからの世界）
 WebRTCを構成するよりローレベルな機能まで１つのObjectとして定義し、
それぞれを直接叩くことが出来るJavaScriptインターフェースを用意する。
 具体的には、WebRTCと並んでW3CのCommunity Groupで議論されている、
ObjectRTC（以下、ORTC）がそれに近い。
 WebRTC 1.0標準化勢は、ORTCの設計思想にインスパイアされ、良い点を
取り込もうとしている。しかしながら、既に仕様が成熟しつつある
WebRTC1.0に、今更全てを取り込むわけにもいかないため、WebRTC1.0と
して実現する機能、その次のWebRTC NVとして実現する機能の仕分けが今、
行われている。
 詳しくは１日目 Dr. Alex Gouaillard のセッションが役に立つに違いない

 ORTCの世界
 各ブロックは全てJSから単独で操作可能なObjectである。
引用元：http://ortc.org/wp-content/uploads/2015/11/ortc.html※WebRTC1.0の世界ではこれがひとくくり

 Offer/Answerモデルからの開放（１）
 WebRTC 1.0では、１：１での双方向コミュニケーションを前提にしていた
ため、Offer/Answerというステートフルなモデルが用いられていた。
 開発者は双方のステートを意識しつつ、アプリ開発を行う必要があり、実
装が複雑になる一面もあった。
1.いくで！
2.はいよ！
3.返すで！
4.ほいさ！

 WebRTCの世界で具体的に何が起こっているのか
 Offer/Answerモデルからの開放（２）
 現在はWebRTCの活用の場も広がり、必ずしも１：１ではない、必ずしも双
方向ではないユースケースが登場している。そういったユースケースでは、
Offer/Answerモデルは逆に使いにくい。（例えば１：多で片方向の映像配
信とか）
 WebRTC NVでは、各オブジェクトに対するJavaScriptからの操作は全て、
ステートレスに行えるようにAPIが設計されている。

 WebRTCの世界で具体的に何が起こっているのか
 SDPからJSONへ
 WebRTC1.0では、Webアプリからブラウザに対して指示を出す際は、SDPと
いうテキストベースのプロトコルを利用するルールになっている。シグナ
リングで互いにメッセージを交換する場合もSDPのフォーマットで交換する。
 先ほどのOffer/Answerモデルの採用は、SDPがそのモデルを想定したプロ
トコルであることに起因している。
 WebRTC NVでは、Webアプリとブラウザ間のデータのやり取りはJSONを
ベースとなり、Web開発者には親しみにやすい仕様になっている。ただし、
既存のWebRTC1.0と相互接続する場合は、JSON→SDP→JSONの変換が必要
となる。

 WebRTC NVを利用した開発例
 WebRTC NVはまだ仕様書もなく実装されているブラウザも存在しない
が、一番近い実装としては、ORTCとそれを実装したMicrosoft Edgeが
相当する。今回はEdgeに実装されたORTCのコードを解説する処理
シーケンスを解説する。

 全てのAPIが仕様通りに実装されているわけではない
 STUNサーバの指定ができない
 TURNサーバが必ず必要
 H.264やVP8に対応していない
 Chrome-Edge/Firefox-Edgeは音声のみ疎通可
 Edge同士であれば H.264UCで映像も疎通可
 ICEはhalf trickle ICEを実装

MediaCapture MediaCapture
localStreamA localStreamB

IceGatherer IceGatherer
ローカルのICE候補を収集する
var iceOptions = new RTCIceGatherOptions;
iceOptions.gatherPolicy = "all";
iceOptions.iceservers = ”turn.xxx.com";
var iceGathr = new RTCIceGatherer(iceOptions);
iceGathr.onlocalcandidate = function(evt) {
mySignaller.signalMessage({
"candidate": evt.candidate
});
};
ローカルのICE Candidateを収集する
var iceOptions = new RTCIceGatherOptions;
iceOptions.gatherPolicy = "all";
iceOptions.iceservers = ”turn.xxx.com";
var iceGathr = new RTCIceGatherer(iceOptions);
iceGather.onlocalcandidate = function(evt) {
mySignaller.signalMessage({
"candidate": evt.candidate
});
};

localStreamBlocalStreamA
CandidateA CandidateB

シグナリングでCandidateを交換

IceTransport IceTransport
ローカルのCandidateとリモートの
Candidateの組み合わせから、通信可能な
経路を探索する。
var iceTr = new RTCIceTransport();
mySignaller.onRemoteCandidate =
function(remote) {
iceTr.addRemoteCandidate(remote.candidate);
}
CandidateB CandidateA
IceTransportオブジェクトを生成する
（ICEによる通信経路確立のための準備）
var iceTr = new RTCIceTransport();
mySignaller.onRemoteCandidate = function(remote) {
iceTr.addRemoteCandidate(remote.candidate);
}

ICE Transport
iceTrObject iceTrObject

DtlsTransport DtlsTransport
DTLSによる暗号通信用の経路を作成する。
var dtlsTr = new RTCDtlsTransport(iceTr);
dtlsTransportオブジェクトを生成する
（鍵交換に利用する、DTLSによる暗号通
信経路生成の準備）
var dtlsTr = new RTCDtlsTransport(iceTr);

dtlsTrObject dtlsTrObject

IceGatherer RTCIceGatherer
IceTransport RTCIceTransport
DtlsTransport RTCDtlsTransport
RtpSender
RtpReceiver
RtpSender
RtpReceiver
localStreamからAudio/Video Trackを取り出して、それを
メディアの送信用オブジェクトを作成する。
var videoTrack = mediaStreamLocal.getVideoTracks()[0];
var videoSender = new RtpSender(videoTrack, dtlsTr);
DtlsTransport オブジェクトとAudio/Videoかを指定して、
受信用オブジェクトを作成する。
var videoReceiver = new RtpReceiver(dtlsTr, “video”);
localStreamからAudio/Video Trackを取り出して、それを
元にメディアの送信用オブジェクトを作成する。（Track単
位でコントロールできるようになる）
var videoTrack = mediaStreamLocal.getVideoTracks()[0];
var videoSender = new RtpSender(videoTrack, dtlsTr);
DtlsTransport オブジェクトとAudio/Videoを指定して、受信
用オブジェクトを作成する。
var videoReceiver = new RtpReceiver(dtlsTr, “video”);

Media Stream Object
MediaStreamTrackA
(VideoTrack)
MediaStreamTrackB
(AudioTrack)

RtpSender
RtpReceiver
RtpSender
RtpReceiver
SenderObject
ReceiverObject
SenderObject
ReceiverObject

RtpSender
RtpReceiver
RtpSender
RtpReceiver
SenderとReceiverの能力を取得する。
例えば、利用できるコーデックの種類等
SenderObject
ReceiverObject
SenderObject
ReceiverObject
Capabilitie
Sender A
Capabilitie
Receiver A
Capabilitie
Sender B
Capabilitie
Receiver B
SenderとReceiverの能力を取得する。
例えば、利用できるコーデックの種類等

RtpSender
RtpReceiver
RtpSender
RtpReceiver
SenderObject
ReceiverObject
Capabilitie
Sender A
SenderObject
ReceiverObject
Capabilitie
Receiver A
シグナリングで
ICE/DTLS Parameter
Capabilitieをそれぞれ交換
Capabilitie
Sender B
Capabilitie
Receiver B
iCE Param A
dtls Param A
iCE Param B
dtls Param B

RtpSender
RtpReceiver
RtpSender
RtpReceiver
SenderObject
ReceiverObject
Capabilitie
Sender A
SenderObject
ReceiverObject
Capabilitie
Receiver A
Capabilitie
Sender B
Capabilitie
Receiver B
iCE Param A
dtls Param A
iCE Param B
dtls Param B
Capabilitie
Sender B
Capabilitie
Receiver B
iCE Param B
dtls Param B
Capabilitie
Sender A
Capabilitie
Receiver A
iCE Param A
dtls Param A

iceTrObject iceTrObjecticeTransport
.start() .start()
※UDPホールパンチングでUDPによる通信経路を確立

.start() .start()
iceTransport
dtlsTransport
※DTLSはSRTPの鍵交換に利用する（DTLS-SRTP）

.start() .start()
iceTransport
SenderObject
.send()
SenderObject
.send()
dtlsTransport
Media Stream A
（VideoTrack/AudioTrack）
Media Stream B

.start() .start()
iceTransport
SenderObject
.send()
SenderObject
.send()
ReceiverObject ReceiverObject
.receive() .receive()
dtlsTransport
Media Stream A
Media Stream B

Render Render
ReceiverオブジェクトからTrackを取得し、
MediaStreamオブジェクトにaddTrackする。
var mediaStreamRemote = new MediaStream();
mediaStreamRemote.addTrack(audioReceiver.track);
mediaStreamRemote.addTrack(videoReceiver.track);
※Track単位でメディアを扱うが、Video要素にア
タッチする際は、MediaStreamオブジェクト単位での
操作する必要あり。
ReceiverObject ReceiverObject

 詳しいコードの記載はこちらを参照
 https://blogs.windows.com/msedgedev/2015/09/18/ortc-api-is-
now-available-in-microsoft-edge/
 https://msdn.microsoft.com/ja-jp/library/mt588497(v=vs.85).aspx
（日本語版）

 ORTCの実装はWebRTC 1.0よりは複雑で直感的にはわかりにくい
（かもしれない）
 WebRTC1.0ではブラウザが隠蔽してた、よりローレベルな機能まで開
発者が触ることが出来るため、開発自体はより複雑なものになり、よ
り幅広い知識が必要になる。
 その反面、トラブルシューティングの時などは、より細かなレベルで
原因分析が可能になるというメリットも有している。
 また、WebRTC1.0よりもユースケースという観点で、実装できる機能
の幅は広がっている。

 WebRTC1.0とORTCは相互接続が出来る
 ORTCがWebRTC1.0よりローレベルなAPIであることを理解してもらう
 まずは、WebRTC 1.0 の復習から・・・

PeerConnection PeerConnection
ICEのConfigを指定して、PeerConnection Object
を生成する。
this.stunServerURL = “stun:stun.XXX.com:3478”;
var config = { iceServers: [{ urls: this.stunServerURL }] };
var .peerConnection = new webkitRTCPeerConnection(config);
必要なイベントをセットする。
peerConnection.onaddstream = function(){};
peerConnection.onicecandidate = function(){};
ICEのConfigを指定して、PeerConnection Object
を生成する。
this.stunServerURL = “stun:stun.XXX.com:3478”;
var config = { iceServers: [{ urls: this.stunServerURL }] };
var .peerConnection = new webkitRTCPeerConnection(config);
必要なイベントをセットする。
peerConnection.onaddstream = function(){};
peerConnection.onicecandidate = function(){};

PC Object PC Object

PC Object PC Object
.addStream() .addStream()

PC Object PC Object
互いのMediaStreamオブジェクトが取得できたら、
Video要素に流し込む
互いのlocalStreamがPCオブジェクトにセットされた

PC Object PC Object
.createOffer()

PC Object PC Object
.setLocalDescription()

PC Object PC Object
SDP A

PC Object PC Object
SDP A
シグナリングでSDPを相手に伝える

PC Object PC Object
SDP A
.setRemoteDescription()

PC Object PC Object
SDP A SDP A

PC Object PC Object
SDP A SDP A
.createAnswer()

PC Object PC Object
SDP A SDP A

PC Object PC Object
SDP A SDP A
SDP B

PC Object PC Object
SDP A SDP A
SDP B
シグナリングでSDPを相手に伝える

PC Object PC Object
SDP A SDP A
SDP B

PC Object PC Object
SDP A SDP A
SDP BSDP B

PC Object PC Object
SDP A SDP A
SDP BSDP B
.onIceCandidate()

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate A
シグナリングでCandidateを相手に伝える

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate A
.addIceCandidate ()

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate A Candidate A

PC Object PC Object
SDP A SDP A
SDP BSDP B
.onIceCandidate()

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate B

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate B
シグナリングでCandidateを相手に伝える

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate B
.addIceCandidate ()

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate BCandidate B

PC Object PC Object
SDP A SDP A
SDP BSDP B
UDPホールパンチングで接続を試行する

PC Object PC Object
SDP A SDP A
SDP BSDP B
.onaddstream() .onaddstream()

PC Object PC Object
SDP A SDP A
SDP BSDP B
localStreamAlocalStreamB
互いのMediaStreamオブジェクトを取得して、Video
要素に流し込む
互いのMediaStreamオブジェクトが取得できたら、
Video要素に流し込む

 WebRTC1.0とORTCは相互接続が出来る
 ORTCがWebRTC1.0よりローレベルなAPIであることを理解してもらう
 次は、adapter.jsに組み込まれているORTC shimの実装を元に相互運
用性を解説する。
※ adapter.js とは？
- webrtc.org が公開しているWebRTC 公式Shim
- Temasys社のadapter.jsとは別物なので注意
https://github.com/webrtc/adapter

PeerConnectionオブジェクトを擬似的に作成す
る(1)
window.RTCPeerConnection = function(config) {
var self = this;
this.onicecandidate = null;
this.onaddstream = null;
this.onremovestream = null;
this.onsignalingstatechange = null;
this.oniceconnectionstatechange = null;
this.onnegotiationneeded = null;
this.ondatachannel = null;
this.localStreams = [];
this.remoteStreams = [];
this.getLocalStreams = function() { return self.localStreams; };
this.getRemoteStreams = function() { return self.remoteStreams; };
this.localDescription = new RTCSessionDescription({
type: '',
sdp: ''
});
this.remoteDescription = new RTCSessionDescription({
type: '',
sdp: ''
});
this.signalingState = 'stable';
this.iceConnectionState = 'new';
this.iceOptions = {
gatherPolicy: 'all',
iceServers: []
};
};

PeerConnectionオブジェクトを擬似的に作成する(2)
※ここはわりとEdgeの実装に合わせてゴニョゴニョ
してる
if (config && config.iceTransportPolicy) {
switch (config.iceTransportPolicy) {
case 'all':
case 'relay':
this.iceOptions.gatherPolicy = config.iceTransportPolicy;
break;
case 'none':
// FIXME: remove once implementation and spec have added this.
throw new TypeError('iceTransportPolicy "none" not supported');
}
}
if (config && config.iceServers) {
// Edge does not like
// 1) stun:
// 2) turn: that does not have all of turn:host:port?transport=udp
this.iceOptions.iceServers = config.iceServers.filter(function(server) {
if (server && server.urls) {
server.urls = server.urls.filter(function(url) {
return url.indexOf('transport=udp') !== -1;
})[0];
return true;
}
return false;
});
}

PC Object PC Object
.addStream() .addStream()
window.RTCPeerConnection.prototype.addStream = function(stream) {
this.localStreams.push(stream.clone());
};
特別な処理は必要ない
window.RTCPeerConnection.prototype.addStream = function(stream) {
this.localStreams.push(stream.clone());
};
※Edgeの仕様上Streamはcloneして渡す必要がある

PC Object PC Object
.createOffer()
処理が盛り沢山
1. WebRTC 1.0準拠のSDPをJSで生成
2. ローカルICE Candidateを収集
var iceGatherer = new RTCIceGatherer(self.iceOptions);
iceGatherer.onlocalcandidate = function(evt) {
:
:
3. Ice and Dtls Transportを生成
var iceTransport = new RTCIceTransport(iceGatherer);
var dtlsTransport = new RTCDtlsTransport(iceTransport);
4. RTPSender/Receiverを生成
var rtpSender = new RTCRtpSender(track, transports.dtlsTransport);
var rtpReceiver = new RTCRtpReceiver(transports.dtlsTransport, kind);

PC Object PC Object
Offer側では先ほど生成したSDP
を保管
this.localDescription = description;

PC Object PC Object
SDP A
OfferのSDPを解析し必要なオブジェクトを生成
1. ローカルICE Candidateを収集
var iceGatherer = new RTCIceGatherer(self.iceOptions);
iceGatherer.onlocalcandidate = function(evt) {
:
:
2. Ice and Dtls Transportオブジェクトを生成
var iceTransport = new RTCIceTransport(iceGatherer);
var dtlsTransport = new RTCDtlsTransport(iceTransport);
3. RTPSender/Receiverオブジェクトを生成
var rtpSender = new RTCRtpSender(track, transports.dtlsTransport);
var rtpReceiver = new RTCRtpReceiver(transports.dtlsTransport, kind);
4. 相手のSDPを保管
this.remoteDescription = description;

PC Object PC Object
SDP A SDP A
.createAnswer()
処理が盛り沢山
1. WebRTC 1.0準拠のSDPをJSで生成
※細かい処理は省略

PC Object PC Object
SDP A SDP A
AnswerのSDPを解析し必要な処理を行う
1. Ice and Dtls Transportの処理を開始する
iceTransport.start(iceGatherer, remoteIceParameters, ‘controlled’);
dtlsTransport.start(remoteDtlsParameters);
2. 自分のSDPを保管
this.localDescription = description;

PC Object PC Object
SDP A SDP A
SDP B
AnswerのSDPを解析し必要な処理を行う
1. Ice and Dtls Transportの処理を開始する
iceTransport.start(iceGatherer, remoteIceParameters, ‘controlling’);
dtlsTransport.start(remoteDtlsParameters);
2. 相手のSDPを保管
this.remoteDescription = description;

PC Object PC Object
SDP A SDP A
SDP BSDP B
.onIceCandidate()
createOffer() の処理の中でセットした
iceGatherer.onlocalcandidate イベントでローカルの
Candidateを取得し、WebRTC 1.0のイベントに置き換えて発
火させる。

PC Object PC Object
SDP A SDP A
SDP BSDP B
Candidate A
.addIceCandidate ()
受信したCandidateを
iceTransport.addRemoteCandidate() でセットする。

PC Object PC Object
SDP A SDP A
SDP BSDP B
UDPホールパンチングで通信経路を確立

PC Object PC Object
SDP A SDP A
SDP BSDP B
createOffer()の処理の中で生成した、 rtpReceiver から
RemoteのMediaStreamTrackを取り出し、MediaStreamオブ
ジェクトにaddTrack()し、 WebRTC 1.0のイベントでプログ
ラム側にコールバックする

PC Object PC Object
SDP A SDP A
SDP BSDP B
setRemoteDescription()の処理の中で生成した、 rtpReceiver
からRemoteのMediaStreamTrackを取り出し、MediaStream
オブジェクトにaddTrack()し、 WebRTC 1.0のイベントでプ
ログラム側にコールバックする

 ORTCのAPIを組み合わせることでWebRTC 1.0のAPIを再現することが
可能
 既存WebRTC 1.0ライブラリをORTC環境で利用したい場合に実装が必要に
なる。
 普通はshimを実装しているadapter.jsを利用するのが一番効率的だが、す
んなり動かない事例場合もあるので、中身の理解は必要。
 SkyWayで利用するPeer.jsは数行の改修を加えて対応
 改修内容は以下のdiffを参照
 https://github.com/nttcom/peerjs/commit/7dedac9c4c8d2681e710f662d15
bca7834251f5d#diff-0e4bfadc2f518e77444db1f92a1d2451
 相互接続以外の使い方としては、アイディア次第ではSFUやMCU
（ChromeのMediaRecorder APIなどと組み合わせも可能）など色々なもの
がJavaScriptで自作可能

 Edge – Edge（Video）
 Chrome – Edge（Audio）

 今回のセッションでお伝えしたいこと
 WebRTC開発は各種フレームワークを利用することが一般的だが、特に業
務で開発を行う場合は、様々なシーンで、開発者のWebRTC力が要求され
るため、内部の仕組みの理解も怠ってはいけない。
 限定的なユースケースを想定しているWebRTC 1.0は、Extensible Webの
流れに従って、セキュアでよりローレベルなAPIを提供するWebRTC NV
（現在ではORTCやWebRTC 1.0に一部取り込まれている）にシフトしつつ
ある。
 WebRTC 1.0と WebRTC NVは決して別のAPIではない。WebRTCはただのビ
デオチャットを実現する技術ではなくなってきている。WebRTC NVのAPI
を組み合わせれば、WebRTC 1.0のAPIの再定義や、更にSFUなどのメディ
アサーバだってブラウザ上で実現できるポテンシャルを秘めている。

 WebRTC標準化について
 http://www.slideshare.net/iwashi86/2015-4-
webrtc
 Extensible Webについて
 https://extensiblewebmanifesto.org/ja/
 http://jxck.hatenablog.com/entry/extensible-
lowlevel-api
 ORTCについて
 http://ortc.org/wp-content/uploads/2015/11/ortc.html
 http://iwashi.co/2015/08/13/ortc-and-webrtc/
 http://jxck.hatenablog.com/entry/ortc-to-
webrtcnv
 http://www.slideshare.net/yusukenaka52/webrtc
ortc-50153479
 EdgeにおけるORTCの実装例
 https://blogs.windows.com/msedgedev/2015/09
/18/ortc-api-is-now-available-in-microsoft-edge/
 https://msdn.microsoft.com/ja-
jp/library/mt588497(v=vs.85).aspx
 Adapter.jsのORTC shimについて
 https://github.com/webrtc/adapter/pull/136

WebRTC NextVersion時代のJavaScript開発

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to WebRTC NextVersion時代のJavaScript開発

Similar to WebRTC NextVersion時代のJavaScript開発 (20)

More from Yusuke Naka

More from Yusuke Naka (15)

Recently uploaded

Recently uploaded (12)

WebRTC NextVersion時代のJavaScript開発