SkyWay UG Kansai #1 スペシャルバージョンです。 元の資料は https://goo.gl/tzJj3X です。

1. Copyright © NTT Communications Corporation. All rights reserved.
#WebRTCSkyWay
SkyWayを使いこなすために
SkyWay UG Kansai #1 スペシャルバージョン
2018.1.12
Yusuke Naka@SkyWay DevRel
@Tukimikage

2. ※この資料は @iwashi86 ⽒の資料をベースにカスタマイズしたものです
元の資料はこちら→ https://goo.gl/tzJj3X

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 の変更⽅針

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接続は 2018/1時点 で、コーデック指定＆帯域指定機能は未対応だが、今後実装予定
ユースケースによっては、
パラメタ設定することでSFUが不要に

50. メタデータ

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

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

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

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

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

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

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

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

59. 映像・⾳声を個別に受信するかどうか選択可能
⾳声は送受信、映像は受信のみの設定で相⼿に発信したい
⾳声のみ受信するで設定で相⼿に発信したい
※joinRoomのmeshモードでも利⽤可能

60. 4. ハックな使い⽅

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

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

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

64. getStats() を使う②
・RTCPeerConnectionオブジェクトをプロパティ経由で取得可能
・これを利⽤してgetStats()を使⽤可能
・_negotiator._pc.getStats() を呼び出す
注：今後、公開APIとして提供予定

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

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

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

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

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

70. • SkyWayを使ってビデオチャットをしながら統計情報を表⽰す
るデモを公開中
参考： WebRTCで統計情報を収集する
https://goo.gl/FxJ9eo

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

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

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

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

75. 少しだけ裏側紹介

76. STUN/TURN

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

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

79. SFU

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

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

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

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

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

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

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

87. SDK対応状況

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

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

90. JavaScript SDKについての補⾜②
・npmを利⽤
・CDNを利⽤
$ npm install -s skyway-js
//cdn.webrtc.ecl.ntt.com/skyway-latest.js

91. iOS SDKについての補⾜①
・iOS SDKの対応状況補⾜
・iOS 8+
・Objective-C / Swiftのサンプルコード公開中

92. iOS SDKについての補⾜②
・CocoaPodsからインストール可能
注：SkyWay-iOS-SDK は 旧SDKなのでご注意を！

93. Android SDKについての補⾜①
・Android SDKの対応状況補⾜
・Android 4.2+ (API Level 17+)
・kotlinのサンプルコードも増やす予定

94. 画⾯共有

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

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

97. 認証

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

99. 認証機能について
・旧トライアル時で利⽤していた⽅法：
・ドメイン認証
・開発者の想定しないドメインに
APIキーを配備された場合に動作させないため
・JavaScript ファイルの場合はAPIキーが隠蔽できず、
ドメインを⾃由に指定できるiOS/Android SDKでは
効果は限定的 ⇒ 新⽅式を提供

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

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

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

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

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

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

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

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

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

109. 注：APIキー認証を有効にするとこのプロセスが必須になる
・利⽤しない場合はチェックをオフにする

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

111. 最後に

112. ・基本的な使い⽅
・応⽤的な使い⽅
・ハックな使い⽅
・その他の機能
今⽇、主にお話したこと

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