More Related Content Similar to 実践 WebRTC 〜最新事例と開発ノウハウの紹介〜 (20) More from Yusuke Naka (20) 実践 WebRTC 〜最新事例と開発ノウハウの紹介〜2. 自己紹介
• 仲 裕介
• Twitter:@Tukimikage
• NTT Communications エンジニア
• WebRTC Platform SkyWay
• デベロッパーリレーション担当
• テクニカルソリューション(テクニカルコンサル/サポート)担当
• コミュニティ運営
• WebRTC Meetup Tokyo / Osaka 主催
• WebRTC Beginners Tokyo 主催
48. PromiseベースのAPI
// let the "negotiationneeded" event trigger offer generation
pc.onnegotiationneeded = function () {
pc.createOffer().then(function (offer) {
return pc.setLocalDescription(offer);
})
.then(function () {
// send the offer to the other peer
signalingChannel.send(JSON.stringify({ "desc":
pc.localDescription }));
})
.catch(logError);
};
49. pc.addTrack
// get a local stream, show it in a self-view and add it to be sent
navigator.mediaDevices.getUserMedia({ "audio": true, "video": true },
function (stream) {
selfView.srcObject = stream;
if (stream.getAudioTracks().length > 0)
pc.addTrack(stream.getAudioTracks()[0], stream);
if (stream.getVideoTracks().length > 0)
pc.addTrack(stream.getVideoTracks()[0], stream);
}, logError);
55. WebRTC1.0ではSDPを利用する
v=0
(…中略…)
a=group:BUNDLE audio video
m=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126
(…中略…)
c=IN IP4 100.1.2.3
a=rtcp:54321 IN IP4 100.1.2.3
a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0
a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0
(…中略…)
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
(…以下略…)
コーデック番号(下部とリンク)
Opus(48000kHzでステレオ)を利⽤したい
必要な情報をSDPというフォーマットで相手に伝える
56. WebRTC1.0ではSDPを利用する
必要な情報をSDPというフォーマットで相手に伝える
v=0
(…中略…)
a=group:BUNDLE audio video
m=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126
(…中略…)
c=IN IP4 100.1.2.3
a=rtcp:54321 IN IP4 100.1.2.3
a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0
a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0
(…中略…)
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
(…以下略…)
ICEの候補
70. 参考:Safariに関する細かいAPI差分
Chrome、Firefoxのノリで使うとつまります
• iPod touchはaudioに未対応です。
• Video要素には、属性として"playsinline"を必ず指定してください。
• 動画の再生には “.play()” をご利用ください。“autoplay” 属性を指定するだけでは、動画
が再生されない場合があります。
• 一部の環境ではWebページ上でユーザ操作が無い場合には、動画が再生されないケースが
ございます。その場合は、クリック/タップなどのユーザ操作が含まれるようにアプリケー
ションを作成ください。
• スクロールやピンチイン・アウト等を契機に、端末がフリーズする場合があります。その場
合は、相手の映像を表示するvideo要素に"position: -webkit-sticky;"を指定すると、改善さ
れる場合があります。
2017/9/20現在
72. getUserMediaという便利APIはあるけれど
// getUserMediaでカメラ、マイクにアクセス
function startVideo() {
navigator.mediaDevices.getUserMedia({video: true, audio: true})
.then(function (stream) { // success
playVideo(localVideo,stream);
localStream = stream; })
.catch(function (error) { // error
console.error('mediaDevice.getUserMedia() error:', error);
return; }); }
// Videoの再生を開始する
function playVideo(element, stream) {
element.srcObject = stream; element.play();
}
73. くせものです…
• getUserMediaのConstraints
• {video: true, audio: true}
• Constraintsとは制約条件のことで、JS開発者はAPIの引き数に制約条件を与え
てカメラ映像やマイク音声を取得する
• オプション指定ではなく制約なので100%その通りになるとは限らない…
• 書き方に幅がある…
• おまけにブラウザごとに実装にムラがある…
• 利用者の環境は千差万別、考えて指定しないとカメラが取得できないです…と
いう問合せがくる…
80. SFU
• SFU(Selective Forwarding Unit)で
映像・音声をコピーし配信
• 送信ストリームは接続台数に関係なく
1本であり、クライアントの負荷を軽
減できる
• WebRTCでは主流の形式
• ソフトウェア方式のSFU(有償/無償)
• PaaSとして提供しているSFUあり
SFU
85. 参考:シグナリング
音声・映像等の通信を開始する前に通信相手と以下の情報を共有・交渉する
No 主要な情報 必要な理由
1 通信を開始したい旨、応答したい旨 どのタイミングで通信を開始して良いかわからないので
2 通信相⼿のIPアドレス・ポート番号 どこにパケットを送れば良いか分からないので
3 トランスポートプロトコル TCP、UDP※のどちらを使えば良いか分からないため
(※特にWebRTCではUDPをRTPでカプセル化している)
4 メディア種別
(⾳声、映像 等)
⾳声のみで通信したいのか、
映像も併⽤したいのか分からないため
5 コーデック
(H.264、VP8 等)
どんなコーデック(符号化⽅式)で
相⼿と通信するか分からないので
6 暗号化情報(鍵・アルゴリズム 等) どんな暗号化⽅式、共有鍵を⽤いるか分からないので
※先述したSDPの記述⽅法でこれらを交換する
90. ICE
• STUN
• NATを越えるためのユーティリティ
• 自分のグローバルIPアドレス、ポート番号を知ることが出来る
• 得られた情報を利用してUDPホールパンチングを実施する
STUN
サーバSTUN
クライアント
(ブラウザ)
NAT
Binding Request
送信元IP:STUNクライアント
送信先IP:STUNサーバ
Binding Request
送信元IP:NATの外側のIP(★)
送信先IP:STUNサーバ
Binding Response
送信元IP:STUNサーバ
送信先IP:NATの外側のIP(★)
本⽂:NATの外側のIP(★)
Binding Response
送信元IP:STUNサーバ
送信先IP:STUNクライアント
本⽂:NATの外側のIP(★)
補⾜:上記フローには、実際には
IPアドレスとポート番号の両⽅が含まれる
98. ICE
• TURN
• UDPホールパンチングで通信ができない場合にメディアを中継する
• FW等でUDPパケットの通信が禁止されている場合にも有効
TURN
サーバ
Aさん:TURN
クライアント
(ブラウザ)
Allocation Request
送信元IP&ポート:STUNクライアント
送信先IP&ポート:TURNサーバ
Allocation Success Response
送信元IP&ポート:STUNサーバ
送信先IP&ポート:TURNクライアント
本⽂:TURNサーバにて中継⽤に
払い出すIPアドレスとポート(★)
Bさん:TURN
クライアント
(ブラウザ)
通信するための準備
99. ICE
• TURN
• UDPホールパンチングで通信ができない場合にメディアを中継する
• FW等でUDPパケットの通信が禁止されている場合にも有効
TURN
サーバ
Aさん:TURN
クライアント
(ブラウザ)
①Create Permissionリクエスト
(★のアドレスを使ってBさんと
通信したいので許可をください)
③メディアを流すと中継してくれる
Bさん:TURN
クライアント
(ブラウザ)
準備が整ったら許可を求める
メディアが中継される
122. SkyWay Developer Meetup #1
■日時 : 2017年9月29日(金)18:30開場 19:00開始
■会場 : いいオフィス 東京都台東区東上野2-18-7共同ビル3F
■定員 : 200名
■参加費: 無料/登録制 事前登録はこちら
※詳しくはイベントサイトをご覧ください。
https://skyway.connpass.com/event/65697/