2017 SkyWayを使いこなすために / How to use SkyWay (WebRTC) in 2017

SkyWay Developers Meetup #1 の資料です。(2017年の資料です）
SkyWayの基本的な使い方から、応用的な使い方までを解説しています。

Transcript

1. Copyright © NTT Communications Corporation. All rights reserved. #WebRTCSkyWay SkyWayを使いこなすために SkyWay Developers Meetup #1 SkyWay Tech Lead @iwashi86 2017.9.29
2. ・岩瀬 義昌 / @iwashi86 ・SkyWayのTech Lead: 　JS/インフラ/サーバアプリなど ・WebRTC関連で色々と発表:
3. SkyWayの基本的な使い方から 応用的な使い方までを知る ⇒ ご自身のアプリ開発に活かす 本セッションのゴール
4. お品書き 1. はじめに 2. 基本的な使い方 3. 応用的な使い方 4. ハックな使い方 5. その他の細かい機能
5. 1. はじめに
6. 2013年に、SkyWayはPeerJSベースでトライアル開始 http://peerjs.com/
7. よくある質問 ・PeerJSはメンテされてないのでは？ 　
8. よくある質問 ・PeerJSはメンテされてないのでは？ 　⇒2015/9 が最終コミット
9. よくある質問 ・PeerJSはメンテされてないのでは？ 　⇒2015/9 が最終コミット ・SkyWayはPeerJSベースなので古い？
10. よくある質問 ・PeerJSはメンテされてないのでは？ 　⇒2015/9 が最終コミット ・SkyWayはPeerJSベースなので古い？ 　⇒No
11. JavaScript SDK について ・外部のAPIはそのままに 　最新のWebRTC APIを使いつつ、 　内部はフルスクラッチ実装
12. JavaScript SDK について ・外部のAPIはそのままに 　最新のWebRTC APIを使いつつ、 　内部はフルスクラッチ実装 　e.g. Safari先行実装の最新APIである RtpTransceiver もSDKで吸収 https://github.com/skyway/skyway-js-sdk/blob/master/src/peer/negotiator.js#L340-L344
13. ・外部APIを残したのは後方互換のため JavaScript SDK について
14. ・外部APIを残したのは後方互換のため ・代表的な関数・メソッドはそのまま利用可能 　⇒ SDKとAPIキーを交換のみで動作 　　 詳細は公式ページを参照： https://webrtc.ecl.ntt.com/migration.html JavaScript SDK について
15. ・Breakingな更新は基本実施しない 　・必要な場合は、先行してDeprecationを出す 　　(特に PeerJS 由来のやや古いAPIの変更時) JavaScript SDK の変更方針
16. ・Breakingな更新は基本実施しない 　・必要な場合は、先行してDeprecationを出す ・セマンティックバージョニング (x.y.z 形式 e.g. 1.0.1) 　・xの変更：後方互換性のない更新 　・yの変更：後方互換性のある機能追加 　・zの変更：後方互換制のあるバグ改修など JavaScript SDK の変更方針 ・//cdn.webrtc.ecl.ntt.com/skyway-latest.js のCDN版を推奨
17. 2. 基本的な使い方 以降 JavaScript ベースで説明するが、iOS/Androidも同様
18. Peer シグナリングサーバ接続
19. Peerオブジェクトの生成① ・内部でシグナリングサーバへ接続
20. Peerオブジェクトの生成① ・内部でシグナリングサーバへ接続 ・成功すると ’open’ イベントが発火、 　 Peer ID※がランダムでサーバから割り当てされる ※ Peer IDとは、イメージ的には電話番号みたいなもの
21. Peerオブジェクトの生成② ・開発者自身が Peer ID 指定も可能 Peer IDの値が重複しないように注意。 重複時はサーバ側でエラーとなる。
22. Peerオブジェクトの生成③ ・詳細なログ出力にはdebugオプションを付与 　WebRTC的にどこで失敗しているのか判別できるので、 　SkyWayサポートへの問い合わせ時などに、返答確率UPかも？
23. Peerオブジェクトの生成④ ・configにオブジェクトを渡すと、 　RTCPeerConnectionのオプションにそのまま渡される
24. Peerオブジェクトの生成④ ・configにオブジェクトを渡すと、 　RTCPeerConnectionのオプションにそのまま渡される 　応用例： TURN限定にする
25. 音声/映像 1:1 接続 MediaChannel
26. P2P Media Channel(音声/映像)で接続する① ・Peer IDを指定して、call関数を呼び出す => 相手に発信
27. P2P Media Channel(音声/映像)で接続する① ・Peer IDを指定して、call関数を呼び出す => 相手に発信 ・相手側で着信すると ’call’ イベントが発火、 　応答可能ならanswer関数を呼び出す
28. P2P Media Channel(音声/映像)で接続する② ・音声/映像は ‘stream’ イベントで取得可能
29. P2P Media Channel(音声/映像)で接続する② ・音声/映像は ‘stream’ イベントで取得可能 <video autoplay> と autoplay と宣言的に設定しても、 自動再生されないケースもあるので、明示的に play() を推奨 モバイルブラウザは、ユーザアクションも必要な点にも注意
30. 音声/映像 ルーム接続 MediaChannel
31. SkyWayではフルメッシュとSFUのルームを提供 フルメッシュ SFU ・クライアントの負荷:大 ・SFUのコスト:無 ・クライアントの負荷:低 ・SFUのコスト:有
32. MultiParty(フルメッシュ / SFU接続) で接続する① ・ルーム名・modeを指定して、 　joinRoom()でルーム参加
33. MultiParty(フルメッシュ / SFU接続) で接続する② ・ルームで新規の音声/映像ストリームがあれば 　‘stream’ イベントを発火
34. サクッと動作感を試したい人へ https://conf.webrtc.ecl.ntt.com/
35. 補足: 旧トライアルのMultiPartyはdeprecated 　以下のライブラリを利用時は 　Room APIへの移行をお願いします！
36. データ 1:1 接続 DataChannel
37. P2P Data Channelで接続する① ・Peer IDを指定して、connect関数を呼び出す
38. P2P Data Channelで接続する① ・Peer IDを指定して、connect関数を呼び出す ・接続されると ‘connection’ イベントが発火する
39. P2P Data Channelで接続する② ・前頁のconnectionを利用して、データ送信
40. P2P Data Channelで接続する② ・前頁のconnectionを利用して、データ送信 ・データを受信すると’data’イベントが発火する
41. データ ルーム接続 DataChannel WebSocket 注： 　現行でWebSocket経由(socket.io)での送付 　フルメッシュ向けのDataChannelは別途開発予定
42. ルーム全体にデータを送る① ・roomオブジェクトを利用して、データ送信
43. ルーム全体にデータを送る② ・roomオブジェクトを利用して、データ送信 ・データを受信すると’data’イベントが発火
44. ルーム全体にデータを送る② ・roomオブジェクトを利用して、データ送信 ・データを受信すると’data’イベントが発火
45. 3. 応用的な使い方
46. コーデック・帯域指定
47. P2P/フルメッシュにて発信時に最大帯域を指定 　ネットワーク帯域が小さい場合、 　TURN利用帯域を節約したい場合などに有効 　補足：上記コード例は call() だが、joinRoom() でも利用可能 e.g. 最大帯域を 200 kbps に設定したい
48. P2P/フルメッシュにて発信時にコーデックを指定 　 　その他： 　VP9にてネットワーク帯域を節約しつつ、映像品質を上げたい 　　などの場合に有効 e.g. H264でハードウェアエンコードを利用して負荷を下げたい
49. 帯域＆コーデック指定の組み合わせも可能 SFU接続は 2017/9時点 で、コーデック指定＆帯域指定機能は未対応だが、今後実装予定 ユースケースによっては、 パラメタ設定することでSFUが不要に
50. メタデータ
51. P2P call時に任意のメタデータを渡す e.g. 発信時に、Peer IDではなく名前を渡したい
52. P2P call時に任意のメタデータを渡す
53. P2P call時に任意のメタデータを渡す
54. 一方向通信 (送信のみ・受信のみ / 配信・視聴)
55. P2Pにて一方向通信(送信専用/受信専用) 配信側は待ち受けしておいて、必要に応じて応答
56. P2Pにて一方向通信(送信専用/受信専用) 配信側は待ち受けしておいて、必要に応じて応答 視聴側はstreamを指定せずに発信
57. 例: 木構造を作れば多段配信可能 遅延を重要視せず、サーバレス＆低コストで かつスケールしたい人向け 配信 Origin 視聴 +中継 視聴 +中継 視聴 視聴 ・ ・ ・ ・ ・ ・ ・・・
58. 4. ハックな使い方
59. 統計情報取得 (選択経路、送受信バイト数など)
60. getStats() を使う① ・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能 ・これを利用してgetStats()を使用可能
61. getStats() を使う② ・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能 ・これを利用してgetStats()を使用可能 ・_negotiator._pc.getStats() を呼び出す
62. getStats() を使う③ : e.g. 送受信量が分かる
63. getStats() を使う③ : e.g. 選択されてる経路が分かる
64. getStats() を使う③ : e.g. 選択されてる経路が分かる
65. getStats() を使う③ : e.g. 選択されてる経路が分かる
66. getStats() を使う③ : e.g. 選択されてる経路が分かる
67. TURN as a Service (SkyWayのTURNのみ使いたい)
68. TURN as a Service として使う SkyWayの提供するTURNサーバだけ使いたい ⇒ new Peer() -> ’open’ の後に以下のプロパティを参照
69. TURN as a Service として使う SkyWayの提供するTURNサーバだけ使いたい ⇒ new Peer() -> ’open’ の後に以下のプロパティを参照
70. TURN as a Service として使う SkyWayの提供するTURNサーバだけ使いたい ⇒ new Peer() -> ’open’ の後に以下のプロパティを参照
71. 少しだけ裏側紹介
72. STUN/TURN
73. STUN/TURNの配置場所 https://pixabay.com/ja/%E4%B8%96%E7%95%8C-%E5%9C%B0%E5%9B%B3-%E5%A4%A7%E9%99%B8-%E5%9B%BD-%E5%9C%B0%E7%90%86%E5%AD%A6-%E6%83%91%E6%98%9F-%E5%9C%B0%E7%90%83-%E3%82%A2%E3%83%95%E3%83%AA%E3%82%AB-%E3%82%A2%E3%82%B8%E3%82%A2-117174/ ・日本/シンガポール/オランダ/米国 ・接続時は最寄り(低レイテンシ)のサーバを選択
74. TURNのトランスポート方式 ・以下全てに対応※ 　・TURN-UDP 　・TURN-TCP 　・TURN-TLS ・ポート番号は 443 (HTTPSで使われるもの) 　⇒ 途中でTLSを解くネットワーク装置(プロキシなど) 　　 が無ければ、接続可能 ※ デスクトップ・モバイル共にブラウザ側が対応していない場合を除く
75. SFU
76. SFUの裏側 ・現時点では配置は東京のみ 　需要を見つつ海外配備していく予定
77. SFUの裏側 ・現時点では配置は東京のみ 　需要を見つつ海外配備していく予定 ・SFUのトランスポート方式 　・ICE-UDP 　・ICE-TCP 　・ICE-SSLTCP (Chromeのみ) 　　・SSLハンドシェイクのみ実施する擬似SSL ・ポート番号は 10000(UDP) / 443 (TCP/SSLTCP)
78. 安定性・スケーラビリティ
79. 安定性、スケーラビリティ ・長期接続も検証済み 　・e.g. 24時間超の動作も 　　　 シグナリング/TURN/SFU含めて確認済み
80. 安定性、スケーラビリティ ・長期接続も検証済み 　・e.g. 24時間超の動作も 　　　 シグナリング/TURN/SFU含めて確認済み ・SkyWayを構成するサーバは全て冗長化
81. 安定性、スケーラビリティ ・長期接続も検証済み 　・e.g. 24時間超の動作も 　　　 シグナリング/TURN/SFU含めて確認済み ・SkyWayを構成するサーバは全て冗長化 ・負荷に応じてスケールアウト、 　12 Factor Appsや、Infrastructure as Code などの 　ベストプラクティスに沿って開発(興味あれば懇親会で)
82. 5. その他 細かいトピック
83. SDK対応状況
84. SDK対応状況: 4種類に対応
85. JavaScript SDKについての補足① ・JavaScript SDKの対応状況補足 　・P2P: Chrome / Firefox / Safari / Edge 　・SFU: Chrome / Firefox 　徐々に追加対応を増やす予定 (e.g. SFU: Safari)
86. JavaScript SDKについての補足②
87. JavaScript SDKについての補足② 　　Thanks to　　　　　　 リリース前のリファクタ・仕上げを中止に お手伝いいただきました。現在も共同開発中です！
88. https://support.skyway.io/hc/ja/articles/115012750968-iOS11%E6%90%AD%E8%BC%89Safari%E3%81%B8%E3%81%AE%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81
89. https://support.skyway.io/hc/ja/articles/115012750968-iOS11%E6%90%AD%E8%BC%89Safari%E3%81%B8%E3%81%AE%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81 ・ただし注意点が多め 　・Video要素に “playsinline” が必要 　・ピンチイン/ピンチアウトでOSごとクラッシュも 　　・CSSにて ”position: -webkit-sticky;” でやや改善
90. 画面共有
91. 画面共有① ・Chrome / Firefox 向けにライブラリを提供 　・Chromeはホワイトリスト方式のため要Extension 　・Firefoxはプラグインが不要
92. 画面共有② ・Promiseベースで動作(内部的にはgetUserMediaを利用)
93. 認証
94. 認証機能について ・旧トライアル時で利用していた方法： 　・ APIキー認証 　・ドメイン認証 　　・開発者の想定しないドメインに 　　　APIキーを配備された場合に動作させないため 　
95. 認証機能について ・旧トライアル時で利用していた方法： 　・ APIキー認証 　・ドメイン認証 　　・開発者の想定しないドメインに 　　　APIキーを配備された場合に動作させないため 　 ・JavaScript ファイルの場合は隠蔽できず、 　認証が弱いのでは？　⇒　新方式を提供
96. シークレットキーを活用した認証 ・正式版SkyWayから追加
97. シークレットキーを活用した認証 ・正式版SkyWayから追加 ・SkyWayへの接続を許可するかどうか、 　自身のロジックで判断可能
98. シークレットキーを活用した認証 ・正式版SkyWayから追加 ・SkyWayへの接続を許可するかどうか、 　自身のロジックで判断可能 ・シークレットキーはダッシュボードから取得
99. 認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報 　 (e.g. トークンやパスワード)を送信 クライアント
100. 認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報 　 (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が 　正しいか確認
101. 認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報 　 (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が 　正しいか確認 3. シークレットキー、 　タイムスタンプなどを 　活用して認証トークン生成※ ※ https://github.com/skyway/skyway-peer-authentication-samples 　 で生成ロジック・参考実装を複数言語で用意済み。
102. 認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報 　 (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が 　正しいか確認 3. シークレットキー、 　タイムスタンプなどを 　活用して認証トークン生成 4. 認証トークンなどを返信
103. 認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報 　 (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が 　正しいか確認 3. シークレットキー、 　タイムスタンプなどを 　活用して認証トークン生成 4. 認証トークンなどを返信 5. 取得した認証トークンを 　 オプション付与してnew Peer()実行
104. 認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報 　 (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が 　正しいか確認 3. シークレットキー、 　タイムスタンプなどを 　活用して認証トークン生成 4. 認証トークンなどを返信 5. 取得した認証トークンを 　 オプション付与してnew Peer()実行 6. 認証トークンが 　 正しいか確認 突 合
105. まとめ
106. ・基本的な使い方 ・応用的な使い方 ・ハックな使い方 ・その他の機能 今日、主にお話したこと
107. 最後に
108. https://www.flickr.com/photos/donkeyhotey/5666065982/in/photolist-9CG51N-iSVsHR-6BwEGo-4FRmzv-TsvWqd-uHbzbq-6mjqJY-b5wN6R-h9pYTx-4a6jX9-s7EWjn-jPUuDi-qDm2oy-qurhKS-afTGc7-8PPonW-56c1Bv-f2BHW3-QWD62z-H5z2n6-T9GYM2-kCSr67-TdZSEE-e4TCJJ-EiD3UR-eemkAU-onnXYp-578snM-8QB2Pq-FDvnar-7ggUqp-dhweee-9CFYBE-54kbk6-oLpFmq-636bwM-RX2Bq7-jo7gvp-WJFsgL-XhKWTw-UhCpCS-W7cMac-W8c9ux-WKBC7Q-HRUzeG-VzJ2Ns-qskcfy-9scYYm-bCS5Qy-dBy9xV 開発要望・機能改善などの フィードバックを お待ちしております！ おしまい