SkyWay Developers Meetup #1 の資料です。(2017年の資料です） SkyWayの基本的な使い方から、応用的な使い方までを解説しています。
Copyright © NTT Communications Corporation. All rights reserved.#WebRTCSkyWaySkyWayを使いこなすためにSkyWay Developers Meetup #1SkyWay Tech Lead@iwashi862017.9.29
View Slide
・岩瀬 義昌 / @iwashi86・SkyWayのTech Lead: JS/インフラ/サーバアプリなど・WebRTC関連で色々と発表:
SkyWayの基本的な使い方から応用的な使い方までを知る⇒ ご自身のアプリ開発に活かす本セッションのゴール
お品書き1. はじめに2. 基本的な使い方3. 応用的な使い方4. ハックな使い方5. その他の細かい機能
1. はじめに
2013年に、SkyWayはPeerJSベースでトライアル開始http://peerjs.com/
よくある質問・PeerJSはメンテされてないのでは？
よくある質問・PeerJSはメンテされてないのでは？ ⇒2015/9 が最終コミット
よくある質問・PeerJSはメンテされてないのでは？ ⇒2015/9 が最終コミット・SkyWayはPeerJSベースなので古い？
よくある質問・PeerJSはメンテされてないのでは？ ⇒2015/9 が最終コミット・SkyWayはPeerJSベースなので古い？ ⇒No
JavaScript SDK について・外部のAPIはそのままに 最新のWebRTC APIを使いつつ、 内部はフルスクラッチ実装
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
・外部APIを残したのは後方互換のためJavaScript SDK について
・外部APIを残したのは後方互換のため・代表的な関数・メソッドはそのまま利用可能 ⇒ SDKとAPIキーを交換のみで動作 詳細は公式ページを参照：https://webrtc.ecl.ntt.com/migration.htmlJavaScript SDK について
・Breakingな更新は基本実施しない ・必要な場合は、先行してDeprecationを出す (特に PeerJS 由来のやや古いAPIの変更時)JavaScript SDK の変更方針
・Breakingな更新は基本実施しない ・必要な場合は、先行してDeprecationを出す・セマンティックバージョニング (x.y.z 形式 e.g. 1.0.1) ・xの変更：後方互換性のない更新 ・yの変更：後方互換性のある機能追加 ・zの変更：後方互換制のあるバグ改修などJavaScript SDK の変更方針・//cdn.webrtc.ecl.ntt.com/skyway-latest.js のCDN版を推奨
2. 基本的な使い方以降 JavaScript ベースで説明するが、iOS/Androidも同様
Peerシグナリングサーバ接続
Peerオブジェクトの生成①・内部でシグナリングサーバへ接続
Peerオブジェクトの生成①・内部でシグナリングサーバへ接続・成功すると ’open’ イベントが発火、 Peer ID※がランダムでサーバから割り当てされる※ Peer IDとは、イメージ的には電話番号みたいなもの
Peerオブジェクトの生成②・開発者自身が Peer ID 指定も可能Peer IDの値が重複しないように注意。重複時はサーバ側でエラーとなる。
Peerオブジェクトの生成③・詳細なログ出力にはdebugオプションを付与 WebRTC的にどこで失敗しているのか判別できるので、 SkyWayサポートへの問い合わせ時などに、返答確率UPかも？
Peerオブジェクトの生成④・configにオブジェクトを渡すと、 RTCPeerConnectionのオプションにそのまま渡される
Peerオブジェクトの生成④・configにオブジェクトを渡すと、 RTCPeerConnectionのオプションにそのまま渡される 応用例： TURN限定にする
音声/映像 1:1 接続MediaChannel
P2P Media Channel(音声/映像)で接続する①・Peer IDを指定して、call関数を呼び出す => 相手に発信
P2P Media Channel(音声/映像)で接続する①・Peer IDを指定して、call関数を呼び出す => 相手に発信・相手側で着信すると ’call’ イベントが発火、 応答可能ならanswer関数を呼び出す
P2P Media Channel(音声/映像)で接続する②・音声/映像は ‘stream’ イベントで取得可能
P2P Media Channel(音声/映像)で接続する②・音声/映像は ‘stream’ イベントで取得可能 と autoplay と宣言的に設定しても、自動再生されないケースもあるので、明示的に play() を推奨モバイルブラウザは、ユーザアクションも必要な点にも注意
音声/映像 ルーム接続MediaChannel
SkyWayではフルメッシュとSFUのルームを提供フルメッシュ SFU・クライアントの負荷:大・SFUのコスト:無・クライアントの負荷:低・SFUのコスト:有
MultiParty(フルメッシュ / SFU接続) で接続する①・ルーム名・modeを指定して、 joinRoom()でルーム参加
MultiParty(フルメッシュ / SFU接続) で接続する②・ルームで新規の音声/映像ストリームがあれば ‘stream’ イベントを発火
サクッと動作感を試したい人へhttps://conf.webrtc.ecl.ntt.com/
補足: 旧トライアルのMultiPartyはdeprecated 以下のライブラリを利用時は Room APIへの移行をお願いします！
データ 1:1 接続DataChannel
P2P Data Channelで接続する①・Peer IDを指定して、connect関数を呼び出す
P2P Data Channelで接続する①・Peer IDを指定して、connect関数を呼び出す・接続されると ‘connection’ イベントが発火する
P2P Data Channelで接続する②・前頁のconnectionを利用して、データ送信
P2P Data Channelで接続する②・前頁のconnectionを利用して、データ送信・データを受信すると’data’イベントが発火する
データ ルーム接続DataChannel WebSocket注： 現行でWebSocket経由(socket.io)での送付 フルメッシュ向けのDataChannelは別途開発予定
ルーム全体にデータを送る①・roomオブジェクトを利用して、データ送信
ルーム全体にデータを送る②・roomオブジェクトを利用して、データ送信・データを受信すると’data’イベントが発火
3. 応用的な使い方
コーデック・帯域指定
P2P/フルメッシュにて発信時に最大帯域を指定 ネットワーク帯域が小さい場合、 TURN利用帯域を節約したい場合などに有効 補足：上記コード例は call() だが、joinRoom() でも利用可能e.g. 最大帯域を 200 kbps に設定したい
P2P/フルメッシュにて発信時にコーデックを指定 その他： VP9にてネットワーク帯域を節約しつつ、映像品質を上げたい などの場合に有効e.g. H264でハードウェアエンコードを利用して負荷を下げたい
帯域＆コーデック指定の組み合わせも可能SFU接続は 2017/9時点 で、コーデック指定＆帯域指定機能は未対応だが、今後実装予定ユースケースによっては、パラメタ設定することでSFUが不要に
メタデータ
P2P call時に任意のメタデータを渡すe.g. 発信時に、Peer IDではなく名前を渡したい
P2P call時に任意のメタデータを渡す
一方向通信(送信のみ・受信のみ / 配信・視聴)
P2Pにて一方向通信(送信専用/受信専用)配信側は待ち受けしておいて、必要に応じて応答
P2Pにて一方向通信(送信専用/受信専用)配信側は待ち受けしておいて、必要に応じて応答視聴側はstreamを指定せずに発信
例: 木構造を作れば多段配信可能遅延を重要視せず、サーバレス＆低コストでかつスケールしたい人向け配信Origin視聴+中継視聴+中継視聴視聴・・・・・・・・・
4. ハックな使い方
統計情報取得(選択経路、送受信バイト数など)
getStats() を使う①・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能・これを利用してgetStats()を使用可能
getStats() を使う②・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能・これを利用してgetStats()を使用可能・_negotiator._pc.getStats() を呼び出す
getStats() を使う③ : e.g. 送受信量が分かる
getStats() を使う③ : e.g. 選択されてる経路が分かる
TURN as a Service(SkyWayのTURNのみ使いたい)
TURN as a Service として使うSkyWayの提供するTURNサーバだけ使いたい⇒ new Peer() -> ’open’ の後に以下のプロパティを参照
少しだけ裏側紹介
STUN/TURN
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/・日本/シンガポール/オランダ/米国・接続時は最寄り(低レイテンシ)のサーバを選択
TURNのトランスポート方式・以下全てに対応※ ・TURN-UDP ・TURN-TCP ・TURN-TLS・ポート番号は 443 (HTTPSで使われるもの) ⇒ 途中でTLSを解くネットワーク装置(プロキシなど) が無ければ、接続可能※ デスクトップ・モバイル共にブラウザ側が対応していない場合を除く
SFU
SFUの裏側・現時点では配置は東京のみ 需要を見つつ海外配備していく予定
SFUの裏側・現時点では配置は東京のみ 需要を見つつ海外配備していく予定・SFUのトランスポート方式 ・ICE-UDP ・ICE-TCP ・ICE-SSLTCP (Chromeのみ) ・SSLハンドシェイクのみ実施する擬似SSL・ポート番号は 10000(UDP) / 443 (TCP/SSLTCP)
安定性・スケーラビリティ
安定性、スケーラビリティ・長期接続も検証済み ・e.g. 24時間超の動作も シグナリング/TURN/SFU含めて確認済み
安定性、スケーラビリティ・長期接続も検証済み ・e.g. 24時間超の動作も シグナリング/TURN/SFU含めて確認済み・SkyWayを構成するサーバは全て冗長化
安定性、スケーラビリティ・長期接続も検証済み ・e.g. 24時間超の動作も シグナリング/TURN/SFU含めて確認済み・SkyWayを構成するサーバは全て冗長化・負荷に応じてスケールアウト、 12 Factor Appsや、Infrastructure as Code などの ベストプラクティスに沿って開発(興味あれば懇親会で)
5. その他 細かいトピック
SDK対応状況
SDK対応状況: 4種類に対応
JavaScript SDKについての補足①・JavaScript SDKの対応状況補足 ・P2P: Chrome / Firefox / Safari / Edge ・SFU: Chrome / Firefox 徐々に追加対応を増やす予定 (e.g. SFU: Safari)
JavaScript SDKについての補足②
JavaScript SDKについての補足② Thanks to リリース前のリファクタ・仕上げを中止にお手伝いいただきました。現在も共同開発中です！
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
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;” でやや改善
画面共有
画面共有①・Chrome / Firefox 向けにライブラリを提供 ・Chromeはホワイトリスト方式のため要Extension ・Firefoxはプラグインが不要
画面共有②・Promiseベースで動作(内部的にはgetUserMediaを利用)
認証
認証機能について・旧トライアル時で利用していた方法： ・ APIキー認証 ・ドメイン認証 ・開発者の想定しないドメインに APIキーを配備された場合に動作させないため
認証機能について・旧トライアル時で利用していた方法： ・ APIキー認証 ・ドメイン認証 ・開発者の想定しないドメインに APIキーを配備された場合に動作させないため ・JavaScript ファイルの場合は隠蔽できず、 認証が弱いのでは？ ⇒ 新方式を提供
シークレットキーを活用した認証・正式版SkyWayから追加
シークレットキーを活用した認証・正式版SkyWayから追加・SkyWayへの接続を許可するかどうか、 自身のロジックで判断可能
シークレットキーを活用した認証・正式版SkyWayから追加・SkyWayへの接続を許可するかどうか、 自身のロジックで判断可能・シークレットキーはダッシュボードから取得
認証フローユーザ側認証Server1. Peer IDと任意の情報 (e.g. トークンやパスワード)を送信クライアント
認証フローユーザ側認証Server1. Peer IDと任意の情報 (e.g. トークンやパスワード)を送信クライアント2. 送信された情報が 正しいか確認
認証フローユーザ側認証Server1. Peer IDと任意の情報 (e.g. トークンやパスワード)を送信クライアント2. 送信された情報が 正しいか確認3. シークレットキー、 タイムスタンプなどを 活用して認証トークン生成※※ https://github.com/skyway/skyway-peer-authentication-samples で生成ロジック・参考実装を複数言語で用意済み。
認証フローユーザ側認証Server1. Peer IDと任意の情報 (e.g. トークンやパスワード)を送信クライアント2. 送信された情報が 正しいか確認3. シークレットキー、 タイムスタンプなどを 活用して認証トークン生成4. 認証トークンなどを返信
認証フローユーザ側認証Server1. Peer IDと任意の情報 (e.g. トークンやパスワード)を送信クライアント2. 送信された情報が 正しいか確認3. シークレットキー、 タイムスタンプなどを 活用して認証トークン生成4. 認証トークンなどを返信5. 取得した認証トークンを オプション付与してnew Peer()実行
認証フローユーザ側認証Server1. Peer IDと任意の情報 (e.g. トークンやパスワード)を送信クライアント2. 送信された情報が 正しいか確認3. シークレットキー、 タイムスタンプなどを 活用して認証トークン生成4. 認証トークンなどを返信5. 取得した認証トークンを オプション付与してnew Peer()実行6. 認証トークンが 正しいか確認突合
まとめ
・基本的な使い方・応用的な使い方・ハックな使い方・その他の機能今日、主にお話したこと
最後に
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開発要望・機能改善などのフィードバックをお待ちしております！おしまい
iwashi86
yshr1200
xibuka
sbtechnight
mizunohiroaki
kthrtty
sparty
ikuyamada
doradora09
ayanonanjo
asazutaiga
ywada526
tomzoh
eitanlees
jasonvnalue
tammielis
62gerente
brad_frost
geeforr
chrisshort
mojombo
marcduiker
mongodb
shpigford
bermonpainter