SkyWayを使いこなすために How to use SkyWay -SkyWay UG Kansai #1 スペシャルバージョン-

Copyright © NTT Communications Corporation. All rights reserved.

#WebRTCSkyWay

SkyWayを使いこなすためにSkyWay UG Kansai #1 スペシャルバージョン

2018.1.12Yusuke Naka@SkyWay DevRel

@Tukimikage

※この資料は @iwashi86 ⽒の資料をベースにカスタマイズしたものです

元の資料はこちら→ https://goo.gl/tzJj3X

SkyWayの基本的な使い⽅から応⽤的な使い⽅までを知る

⇒ ご⾃⾝のアプリ開発に活かす

本セッションのゴール

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

1. はじめに

2013年に、SkyWayはPeerJSベースでトライアル開始

http://peerjs.com/

よくある質問

・PeerJSはメンテされてないのでは？

よくある質問

・PeerJSはメンテされてないのでは？⇒2015/9 が最終コミット

よくある質問


・SkyWayはPeerJSベースなので古い？

よくある質問


・SkyWayはPeerJSベースなので古い？

⇒No

JavaScript SDK について

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


・外部の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を残したのは後⽅互換のため


・外部APIを残したのは後⽅互換のため

・代表的な関数・メソッドはそのまま利⽤可能⇒ SDKとAPIキーを交換のみで動作

詳細は公式ページを参照：

https://webrtc.ecl.ntt.com/migration.html


・Breakingな更新は基本実施しない・必要な場合は、先⾏してDeprecationを出す

(特に PeerJS 由来のやや古いAPIの変更時)

JavaScript SDK の変更⽅針

・Breakingな更新は基本実施しない・必要な場合は、先⾏してDeprecationを出す

・セマンティックバージョニング (x.y.z 形式 e.g. 1.0.1)・xの変更：後⽅互換性のない更新・yの変更：後⽅互換性のある機能追加・zの変更：後⽅互換制のあるバグ改修など

JavaScript SDK の変更⽅針

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ʼ イベントで取得可能

<video autoplay> と 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ʼイベントが発⽕

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

・データを受信するとʼdataʼイベントが発⽕

3. 応⽤的な使い⽅

コーデック・帯域指定

P2P/フルメッシュにて発信時に最⼤帯域を指定

ネットワーク帯域が⼩さい場合、TURN利⽤帯域を節約したい場合などに有効

補⾜：上記コード例は call() だが、joinRoom() でも利⽤可能

e.g. 最⼤帯域を 200 kbps に設定したい

P2P/フルメッシュにて発信時にコーデックを指定

その他：VP9にてネットワーク帯域を節約しつつ、映像品質を上げたい

などの場合に有効

e.g. H264でハードウェアエンコードを利⽤して負荷を下げたい

帯域＆コーデック指定の組み合わせも可能

SFU接続は 2018/1時点で、コーデック指定＆帯域指定機能は未対応だが、今後実装予定

ユースケースによっては、パラメタ設定することでSFUが不要に

メタデータ

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

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

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

⼀⽅向通信(送信のみ・受信のみ / 配信・視聴)

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

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

視聴側はstreamを指定せずに発信

映像・⾳声の受信可否制御

映像・⾳声を個別に受信するかどうか選択可能⾳声は送受信、映像は受信のみの設定で相⼿に発信したい

映像・⾳声を個別に受信するかどうか選択可能⾳声は送受信、映像は受信のみの設定で相⼿に発信したい

⾳声のみ受信するで設定で相⼿に発信したい

※joinRoomのmeshモードでも利⽤可能

4. ハックな使い⽅

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

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

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

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

注：今後、公開APIとして提供予定

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

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




• SkyWayを使ってビデオチャットをしながら統計情報を表⽰するデモを公開中

参考： WebRTCで統計情報を収集する

https://goo.gl/FxJ9eo

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含めて確認済み



・SkyWayを構成するサーバは全て冗⻑化



・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についての補⾜②・npmを利⽤

・CDNを利⽤

$ npm install -s skyway-js

//cdn.webrtc.ecl.ntt.com/skyway-latest.js

iOS SDKについての補⾜①

・iOS SDKの対応状況補⾜・iOS 8+

・Objective-C / Swiftのサンプルコード公開中

iOS SDKについての補⾜②

・CocoaPodsからインストール可能

注：SkyWay-iOS-SDK は旧SDKなのでご注意を！

Android SDKについての補⾜①

・Android SDKの対応状況補⾜・Android 4.2+ (API Level 17+)

・kotlinのサンプルコードも増やす予定

画⾯共有

画⾯共有①・Chrome / Firefox 向けにライブラリを提供

・Chromeはホワイトリスト⽅式のため要Extension・Firefoxはプラグインが不要

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

認証

認証機能について・旧トライアル時で利⽤していた⽅法：

・ドメイン認証・開発者の想定しないドメインに

APIキーを配備された場合に動作させないため

認証機能について・旧トライアル時で利⽤していた⽅法：

・ドメイン認証・開発者の想定しないドメインに

APIキーを配備された場合に動作させないため

・JavaScript ファイルの場合はAPIキーが隠蔽できず、ドメインを⾃由に指定できるiOS/Android SDKでは効果は限定的 ⇒ 新⽅式を提供

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


・SkyWayへの接続を許可するかどうか、⾃⾝のロジックで判断可能


・SkyWayへの接続を許可するかどうか、⾃⾝のロジックで判断可能

・シークレットキーはダッシュボードから取得

認証フロー

ユーザ側認証Server

1. Peer IDと任意の情報(e.g. トークンやパスワード)を送信

クライアント

認証フロー



クライアント

2. 送信された情報が正しいか確認

認証フロー



クライアント


3. シークレットキー、タイムスタンプなどを活⽤して認証トークン⽣成※

※ https://github.com/skyway/skyway-peer-authentication-samples で⽣成ロジック・参考実装を複数⾔語で⽤意済み。

認証フロー



クライアント


3. シークレットキー、タイムスタンプなどを活⽤して認証トークン⽣成

4. 認証トークンなどを返信

認証フロー



クライアント




5. 取得した認証トークンをオプション付与してnew Peer()実⾏

認証フロー



クライアント




5. 取得した認証トークンをオプション付与してnew Peer()実⾏

6. 認証トークンが正しいか確認

突合

注：APIキー認証を有効にするとこのプロセスが必須になる

・利⽤しない場合はチェックをオフにする

参考：⼿軽に使ってみたい⽅・ reCAPTCHAとSkyWayのAPI認証で⼿軽に利⽤できて不正利⽤に強いアプリを作ろう

https://goo.gl/nq3vaH

最後に

・基本的な使い⽅

・応⽤的な使い⽅

・ハックな使い⽅

・その他の機能

今⽇、主にお話したこと

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

開発要望・機能改善などのフィードバックを

お待ちしております！

おしまい

Technology

SkyWayを使いこなすために How to use SkyWay -SkyWay UG Kansai #1 スペシャルバージョン-