Slide 1

Slide 1 text

Copyright © NTT Communications Corporation. All rights reserved. #WebRTCSkyWay SkyWayを使いこなすために SkyWay Developers Meetup #1 SkyWay Tech Lead @iwashi86 2017.9.29

Slide 2

Slide 2 text

・岩瀬 義昌 / @iwashi86 ・SkyWayのTech Lead:  JS/インフラ/サーバアプリなど ・WebRTC関連で色々と発表:

Slide 3

Slide 3 text

SkyWayの基本的な使い方から 応用的な使い方までを知る ⇒ ご自身のアプリ開発に活かす 本セッションのゴール

Slide 4

Slide 4 text

お品書き 1. はじめに 2. 基本的な使い方 3. 応用的な使い方 4. ハックな使い方 5. その他の細かい機能

Slide 5

Slide 5 text

1. はじめに

Slide 6

Slide 6 text

2013年に、SkyWayはPeerJSベースでトライアル開始 http://peerjs.com/

Slide 7

Slide 7 text

よくある質問 ・PeerJSはメンテされてないのでは?  

Slide 8

Slide 8 text

よくある質問 ・PeerJSはメンテされてないのでは?  ⇒2015/9 が最終コミット

Slide 9

Slide 9 text

よくある質問 ・PeerJSはメンテされてないのでは?  ⇒2015/9 が最終コミット ・SkyWayはPeerJSベースなので古い?

Slide 10

Slide 10 text

よくある質問 ・PeerJSはメンテされてないのでは?  ⇒2015/9 が最終コミット ・SkyWayはPeerJSベースなので古い?  ⇒No

Slide 11

Slide 11 text

JavaScript SDK について ・外部のAPIはそのままに  最新のWebRTC APIを使いつつ、  内部はフルスクラッチ実装

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

・外部APIを残したのは後方互換のため JavaScript SDK について

Slide 14

Slide 14 text

・外部APIを残したのは後方互換のため ・代表的な関数・メソッドはそのまま利用可能  ⇒ SDKとAPIキーを交換のみで動作    詳細は公式ページを参照: https://webrtc.ecl.ntt.com/migration.html JavaScript SDK について

Slide 15

Slide 15 text

・Breakingな更新は基本実施しない  ・必要な場合は、先行してDeprecationを出す   (特に PeerJS 由来のやや古いAPIの変更時) JavaScript SDK の変更方針

Slide 16

Slide 16 text

・Breakingな更新は基本実施しない  ・必要な場合は、先行してDeprecationを出す ・セマンティックバージョニング (x.y.z 形式 e.g. 1.0.1)  ・xの変更:後方互換性のない更新  ・yの変更:後方互換性のある機能追加  ・zの変更:後方互換制のあるバグ改修など JavaScript SDK の変更方針 ・//cdn.webrtc.ecl.ntt.com/skyway-latest.js のCDN版を推奨

Slide 17

Slide 17 text

2. 基本的な使い方 以降 JavaScript ベースで説明するが、iOS/Androidも同様

Slide 18

Slide 18 text

Peer シグナリングサーバ接続

Slide 19

Slide 19 text

Peerオブジェクトの生成① ・内部でシグナリングサーバへ接続

Slide 20

Slide 20 text

Peerオブジェクトの生成① ・内部でシグナリングサーバへ接続 ・成功すると ’open’ イベントが発火、   Peer ID※がランダムでサーバから割り当てされる ※ Peer IDとは、イメージ的には電話番号みたいなもの

Slide 21

Slide 21 text

Peerオブジェクトの生成② ・開発者自身が Peer ID 指定も可能 Peer IDの値が重複しないように注意。 重複時はサーバ側でエラーとなる。

Slide 22

Slide 22 text

Peerオブジェクトの生成③ ・詳細なログ出力にはdebugオプションを付与  WebRTC的にどこで失敗しているのか判別できるので、  SkyWayサポートへの問い合わせ時などに、返答確率UPかも?

Slide 23

Slide 23 text

Peerオブジェクトの生成④ ・configにオブジェクトを渡すと、  RTCPeerConnectionのオプションにそのまま渡される

Slide 24

Slide 24 text

Peerオブジェクトの生成④ ・configにオブジェクトを渡すと、  RTCPeerConnectionのオプションにそのまま渡される  応用例: TURN限定にする

Slide 25

Slide 25 text

音声/映像 1:1 接続 MediaChannel

Slide 26

Slide 26 text

P2P Media Channel(音声/映像)で接続する① ・Peer IDを指定して、call関数を呼び出す => 相手に発信

Slide 27

Slide 27 text

P2P Media Channel(音声/映像)で接続する① ・Peer IDを指定して、call関数を呼び出す => 相手に発信 ・相手側で着信すると ’call’ イベントが発火、  応答可能ならanswer関数を呼び出す

Slide 28

Slide 28 text

P2P Media Channel(音声/映像)で接続する② ・音声/映像は ‘stream’ イベントで取得可能

Slide 29

Slide 29 text

P2P Media Channel(音声/映像)で接続する② ・音声/映像は ‘stream’ イベントで取得可能 と autoplay と宣言的に設定しても、 自動再生されないケースもあるので、明示的に play() を推奨 モバイルブラウザは、ユーザアクションも必要な点にも注意

Slide 30

Slide 30 text

音声/映像 ルーム接続 MediaChannel

Slide 31

Slide 31 text

SkyWayではフルメッシュとSFUのルームを提供 フルメッシュ SFU ・クライアントの負荷:大 ・SFUのコスト:無 ・クライアントの負荷:低 ・SFUのコスト:有

Slide 32

Slide 32 text

MultiParty(フルメッシュ / SFU接続) で接続する① ・ルーム名・modeを指定して、  joinRoom()でルーム参加

Slide 33

Slide 33 text

MultiParty(フルメッシュ / SFU接続) で接続する② ・ルームで新規の音声/映像ストリームがあれば  ‘stream’ イベントを発火

Slide 34

Slide 34 text

サクッと動作感を試したい人へ https://conf.webrtc.ecl.ntt.com/

Slide 35

Slide 35 text

補足: 旧トライアルのMultiPartyはdeprecated  以下のライブラリを利用時は  Room APIへの移行をお願いします!

Slide 36

Slide 36 text

データ 1:1 接続 DataChannel

Slide 37

Slide 37 text

P2P Data Channelで接続する① ・Peer IDを指定して、connect関数を呼び出す

Slide 38

Slide 38 text

P2P Data Channelで接続する① ・Peer IDを指定して、connect関数を呼び出す ・接続されると ‘connection’ イベントが発火する

Slide 39

Slide 39 text

P2P Data Channelで接続する② ・前頁のconnectionを利用して、データ送信

Slide 40

Slide 40 text

P2P Data Channelで接続する② ・前頁のconnectionを利用して、データ送信 ・データを受信すると’data’イベントが発火する

Slide 41

Slide 41 text

データ ルーム接続 DataChannel WebSocket 注:  現行でWebSocket経由(socket.io)での送付  フルメッシュ向けのDataChannelは別途開発予定

Slide 42

Slide 42 text

ルーム全体にデータを送る① ・roomオブジェクトを利用して、データ送信

Slide 43

Slide 43 text

ルーム全体にデータを送る② ・roomオブジェクトを利用して、データ送信 ・データを受信すると’data’イベントが発火

Slide 44

Slide 44 text

ルーム全体にデータを送る② ・roomオブジェクトを利用して、データ送信 ・データを受信すると’data’イベントが発火

Slide 45

Slide 45 text

3. 応用的な使い方

Slide 46

Slide 46 text

コーデック・帯域指定

Slide 47

Slide 47 text

P2P/フルメッシュにて発信時に最大帯域を指定  ネットワーク帯域が小さい場合、  TURN利用帯域を節約したい場合などに有効  補足:上記コード例は call() だが、joinRoom() でも利用可能 e.g. 最大帯域を 200 kbps に設定したい

Slide 48

Slide 48 text

P2P/フルメッシュにて発信時にコーデックを指定    その他:  VP9にてネットワーク帯域を節約しつつ、映像品質を上げたい   などの場合に有効 e.g. H264でハードウェアエンコードを利用して負荷を下げたい

Slide 49

Slide 49 text

帯域&コーデック指定の組み合わせも可能 SFU接続は 2017/9時点 で、コーデック指定&帯域指定機能は未対応だが、今後実装予定 ユースケースによっては、 パラメタ設定することでSFUが不要に

Slide 50

Slide 50 text

メタデータ

Slide 51

Slide 51 text

P2P call時に任意のメタデータを渡す e.g. 発信時に、Peer IDではなく名前を渡したい

Slide 52

Slide 52 text

P2P call時に任意のメタデータを渡す

Slide 53

Slide 53 text

P2P call時に任意のメタデータを渡す

Slide 54

Slide 54 text

一方向通信 (送信のみ・受信のみ / 配信・視聴)

Slide 55

Slide 55 text

P2Pにて一方向通信(送信専用/受信専用) 配信側は待ち受けしておいて、必要に応じて応答

Slide 56

Slide 56 text

P2Pにて一方向通信(送信専用/受信専用) 配信側は待ち受けしておいて、必要に応じて応答 視聴側はstreamを指定せずに発信

Slide 57

Slide 57 text

例: 木構造を作れば多段配信可能 遅延を重要視せず、サーバレス&低コストで かつスケールしたい人向け 配信 Origin 視聴 +中継 視聴 +中継 視聴 視聴 ・ ・ ・ ・ ・ ・ ・・・

Slide 58

Slide 58 text

4. ハックな使い方

Slide 59

Slide 59 text

統計情報取得 (選択経路、送受信バイト数など)

Slide 60

Slide 60 text

getStats() を使う① ・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能 ・これを利用してgetStats()を使用可能

Slide 61

Slide 61 text

getStats() を使う② ・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能 ・これを利用してgetStats()を使用可能 ・_negotiator._pc.getStats() を呼び出す

Slide 62

Slide 62 text

getStats() を使う③ : e.g. 送受信量が分かる

Slide 63

Slide 63 text

getStats() を使う③ : e.g. 選択されてる経路が分かる

Slide 64

Slide 64 text

getStats() を使う③ : e.g. 選択されてる経路が分かる

Slide 65

Slide 65 text

getStats() を使う③ : e.g. 選択されてる経路が分かる

Slide 66

Slide 66 text

getStats() を使う③ : e.g. 選択されてる経路が分かる

Slide 67

Slide 67 text

TURN as a Service (SkyWayのTURNのみ使いたい)

Slide 68

Slide 68 text

TURN as a Service として使う SkyWayの提供するTURNサーバだけ使いたい ⇒ new Peer() -> ’open’ の後に以下のプロパティを参照

Slide 69

Slide 69 text

TURN as a Service として使う SkyWayの提供するTURNサーバだけ使いたい ⇒ new Peer() -> ’open’ の後に以下のプロパティを参照

Slide 70

Slide 70 text

TURN as a Service として使う SkyWayの提供するTURNサーバだけ使いたい ⇒ new Peer() -> ’open’ の後に以下のプロパティを参照

Slide 71

Slide 71 text

少しだけ裏側紹介

Slide 72

Slide 72 text

STUN/TURN

Slide 73

Slide 73 text

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/ ・日本/シンガポール/オランダ/米国 ・接続時は最寄り(低レイテンシ)のサーバを選択

Slide 74

Slide 74 text

TURNのトランスポート方式 ・以下全てに対応※  ・TURN-UDP  ・TURN-TCP  ・TURN-TLS ・ポート番号は 443 (HTTPSで使われるもの)  ⇒ 途中でTLSを解くネットワーク装置(プロキシなど)    が無ければ、接続可能 ※ デスクトップ・モバイル共にブラウザ側が対応していない場合を除く

Slide 75

Slide 75 text

SFU

Slide 76

Slide 76 text

SFUの裏側 ・現時点では配置は東京のみ  需要を見つつ海外配備していく予定

Slide 77

Slide 77 text

SFUの裏側 ・現時点では配置は東京のみ  需要を見つつ海外配備していく予定 ・SFUのトランスポート方式  ・ICE-UDP  ・ICE-TCP  ・ICE-SSLTCP (Chromeのみ)   ・SSLハンドシェイクのみ実施する擬似SSL ・ポート番号は 10000(UDP) / 443 (TCP/SSLTCP)

Slide 78

Slide 78 text

安定性・スケーラビリティ

Slide 79

Slide 79 text

安定性、スケーラビリティ ・長期接続も検証済み  ・e.g. 24時間超の動作も     シグナリング/TURN/SFU含めて確認済み

Slide 80

Slide 80 text

安定性、スケーラビリティ ・長期接続も検証済み  ・e.g. 24時間超の動作も     シグナリング/TURN/SFU含めて確認済み ・SkyWayを構成するサーバは全て冗長化

Slide 81

Slide 81 text

安定性、スケーラビリティ ・長期接続も検証済み  ・e.g. 24時間超の動作も     シグナリング/TURN/SFU含めて確認済み ・SkyWayを構成するサーバは全て冗長化 ・負荷に応じてスケールアウト、  12 Factor Appsや、Infrastructure as Code などの  ベストプラクティスに沿って開発(興味あれば懇親会で)

Slide 82

Slide 82 text

5. その他 細かいトピック

Slide 83

Slide 83 text

SDK対応状況

Slide 84

Slide 84 text

SDK対応状況: 4種類に対応

Slide 85

Slide 85 text

JavaScript SDKについての補足① ・JavaScript SDKの対応状況補足  ・P2P: Chrome / Firefox / Safari / Edge  ・SFU: Chrome / Firefox  徐々に追加対応を増やす予定 (e.g. SFU: Safari)

Slide 86

Slide 86 text

JavaScript SDKについての補足②

Slide 87

Slide 87 text

JavaScript SDKについての補足②   Thanks to       リリース前のリファクタ・仕上げを中止に お手伝いいただきました。現在も共同開発中です!

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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;” でやや改善

Slide 90

Slide 90 text

画面共有

Slide 91

Slide 91 text

画面共有① ・Chrome / Firefox 向けにライブラリを提供  ・Chromeはホワイトリスト方式のため要Extension  ・Firefoxはプラグインが不要

Slide 92

Slide 92 text

画面共有② ・Promiseベースで動作(内部的にはgetUserMediaを利用)

Slide 93

Slide 93 text

認証

Slide 94

Slide 94 text

認証機能について ・旧トライアル時で利用していた方法:  ・ APIキー認証  ・ドメイン認証   ・開発者の想定しないドメインに    APIキーを配備された場合に動作させないため  

Slide 95

Slide 95 text

認証機能について ・旧トライアル時で利用していた方法:  ・ APIキー認証  ・ドメイン認証   ・開発者の想定しないドメインに    APIキーを配備された場合に動作させないため   ・JavaScript ファイルの場合は隠蔽できず、  認証が弱いのでは? ⇒ 新方式を提供

Slide 96

Slide 96 text

シークレットキーを活用した認証 ・正式版SkyWayから追加

Slide 97

Slide 97 text

シークレットキーを活用した認証 ・正式版SkyWayから追加 ・SkyWayへの接続を許可するかどうか、  自身のロジックで判断可能

Slide 98

Slide 98 text

シークレットキーを活用した認証 ・正式版SkyWayから追加 ・SkyWayへの接続を許可するかどうか、  自身のロジックで判断可能 ・シークレットキーはダッシュボードから取得

Slide 99

Slide 99 text

認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報   (e.g. トークンやパスワード)を送信 クライアント

Slide 100

Slide 100 text

認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報   (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が  正しいか確認

Slide 101

Slide 101 text

認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報   (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が  正しいか確認 3. シークレットキー、  タイムスタンプなどを  活用して認証トークン生成※ ※ https://github.com/skyway/skyway-peer-authentication-samples   で生成ロジック・参考実装を複数言語で用意済み。

Slide 102

Slide 102 text

認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報   (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が  正しいか確認 3. シークレットキー、  タイムスタンプなどを  活用して認証トークン生成 4. 認証トークンなどを返信

Slide 103

Slide 103 text

認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報   (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が  正しいか確認 3. シークレットキー、  タイムスタンプなどを  活用して認証トークン生成 4. 認証トークンなどを返信 5. 取得した認証トークンを   オプション付与してnew Peer()実行

Slide 104

Slide 104 text

認証フロー ユーザ側 認証Server 1. Peer IDと任意の情報   (e.g. トークンやパスワード)を送信 クライアント 2. 送信された情報が  正しいか確認 3. シークレットキー、  タイムスタンプなどを  活用して認証トークン生成 4. 認証トークンなどを返信 5. 取得した認証トークンを   オプション付与してnew Peer()実行 6. 認証トークンが   正しいか確認 突 合

Slide 105

Slide 105 text

まとめ

Slide 106

Slide 106 text

・基本的な使い方 ・応用的な使い方 ・ハックな使い方 ・その他の機能 今日、主にお話したこと

Slide 107

Slide 107 text

最後に

Slide 108

Slide 108 text

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 開発要望・機能改善などの フィードバックを お待ちしております! おしまい