Tweet
Tweet

Slide 1

Slide 1 text

WebRTCアプリケーションの
 テストの課題・解決方法について 2016/2/17(Wed) @ WebRTC Conference Japan 岩瀬 義昌(NTTコミュニケーションズ株式会社) 瀧川 顕謙(株式会社 ネフロック)

Slide 2

Slide 2 text

■名前
 岩瀬 義昌/ @iwashi86
 ■仕事
 株式会社NTTコミュンケーションズ
 SkyWayの開発・運用
 ■名前
 瀧川 顕謙/ @kenkenkenken8 ■仕事
 株式会社ネフロック CTO


Slide 3

Slide 3 text

全体のアジェンダ
 1. なぜWebRTCアプリのテストが必要なのか？
 なぜ難しいのか？　　　　　　　　　　　　 (10分) 
 2. WebRTCアプリのテストに必要な知識 (15分) 
 3. SkyWayにおけるWebRTCテストの実装例 (20分)


Slide 4

Slide 4 text

WebRTCの導入パターン サンプル開発・検証
 社内でトライアル導入
 お客様とのチャネルで導入
 例：簡単なビデオチャットアプリを開発 
 例：社内会議で実験導入
 例：カスタマサポートの1チャネルとして導入 


Slide 5

Slide 5 text

当初の検証は良好！

Slide 6

Slide 6 text

ケース１: 突然 利用不可に

Slide 7

Slide 7 text

実例：getUserMediaがある日突然 動かない

Slide 8

Slide 8 text

ケース2: UXの低下 https://www.flickr.com/photos/isengardt/11528272293/in/photolist-iyHpHp-96znoi-8Vr7rf-8Vo4zz-8Vo4wR-8Vr7aq-8Vr77S-8Vo4mg-8Vr6YL-8Vr6SU-8Vo48R-8Vr6LL-8Vo41M-8Vr6Cm-8Vo3ST-8Vo3KB-8Vr6nJ-8Vr6jA-8Vr6hb-8Vr6dQ-8Vr6bf-8Vo3rg-8Vo3ov-8Vo3k4-8Vr5Y1-8Vr5U1-8Vo3b6-8Vo35R-8Vo318-8Vo2Xk-wfbkd8-f 6oLfo-optAJc-4wbsVB-82XBKu-4vXavY-kyhZm-kyhXT-7uXm7F-5bQJSE-5bQJFJ-5bLtgR-5bQJhu-5bQJ6q-5bLsEi-5bQHGb-5bLsbk-5bQHaC-5bLrRT-5bQGPG

Slide 9

Slide 9 text

ケース2: 多様な通信条件 ラップトップ x Wifi スマフォ x LTE テザリング x タブレット インターネット WebRTCのクライアントの種類・NW条件は本当に多様であり、ある環境ではUX低下という事象もありえます。


Slide 10

Slide 10 text

悲劇をおこさないために 開発
 そうならないためには、開発をしたら・・・


Slide 11

Slide 11 text

悲劇をおこさないために 開発
 テスト
 もちろんテストが必要です。不具合があれば、開発にフィードバックして修正をします。ただしそのテストが…


Slide 12

Slide 12 text

悲劇をおこさないために 開発
 テスト
 WebRTCのテストは難しい！
 難しいのには、いくつか理由があります。それは…


Slide 13

Slide 13 text

なぜ難しいのか？ 1. 世の中にあるノウハウが少ない
 • スタートアップ：リソース不足でテストも不足
 • 大きめの企業：新機能の実装に多忙
 • テストするにしても手動で頑張る
 
 2. Web/VoIP系の
 テストノウハウを転用しにくい
 
 3. テスト条件が非常に複雑


Slide 14

Slide 14 text

Video 1 Video2 ① ② ③ 手動テス卜の例 ①、②、③を手作業でマウスでクリックして検証というのは、よくあるケースです。


Slide 15

Slide 15 text

続：なぜ難しいのか？ 1. 世の中にあるノウハウが少ない
 • スタートアップ：リソース不足でテストも不足
 • 大きめの企業：新機能の実装に多忙
 • テストするにしても手動で頑張る
 
 2. Web/VoIP系の
 テストノウハウを転用しにくい
 
 3. テスト条件が非常に複雑
 WebRTCの開発者は、もともとVoIP系をやっていた、Webエンジニアであったという人がいます。


Slide 16

Slide 16 text

VoIP側からの視点

Slide 17

Slide 17 text

VoIPテストの例 オンプレミスで実機テスト SIPサーバ/ IP-PBX


Slide 18

Slide 18 text

VoIPテストの例 標準化は低速 SIPサーバ/ IP-PBX


Slide 19

Slide 19 text

VoIPテストの例 低頻度の
 アップデート 標準化は低速 SIPサーバ/ IP-PBX


Slide 20

Slide 20 text

WebRTCに置き換えると 独自シグナリング https://commons.wikimedia.org/wiki/File:Google_Chrome_icon_and_wordmark_(2011).svg https://en.wikipedia.org/wiki/Firefox#/media/File:Mozilla_Firefox_logo_2013.svg

Slide 21

Slide 21 text

WebRTCに置き換えると 標準は無し https://commons.wikimedia.org/wiki/File:Google_Chrome_icon_and_wordmark_(2011).svg https://en.wikipedia.org/wiki/Firefox#/media/File:Mozilla_Firefox_logo_2013.svg 独自シグナリング

Slide 22

Slide 22 text

WebRTCに置き換えると 1-1.5ヶ月で
 アップデート 標準は無し https://commons.wikimedia.org/wiki/File:Google_Chrome_icon_and_wordmark_(2011).svg https://en.wikipedia.org/wiki/Firefox#/media/File:Mozilla_Firefox_logo_2013.svg 1-1.5ヶ月で
 アップデート 独自シグナリング このアップデートがかなり厄介で、WebRTCプラットフォーマからすると


Slide 23

Slide 23 text

こんな風に見えてます
 1-1.5ヶ月で
 アップデート 標準は無し https://commons.wikimedia.org/wiki/File:Google_Chrome_icon_and_wordmark_(2011).svg https://en.wikipedia.org/wiki/Firefox#/media/File:Mozilla_Firefox_logo_2013.svg 1-1.5ヶ月で
 アップデート 独自シグナリング

Slide 24

Slide 24 text

Web側からの視点

Slide 25

Slide 25 text

WebRTCのプロトコルスタック
 UDP-IP/TCP-IP
 ICE
 DTLS
 SRTP
 SCTP
 Audio/Video
 Data


Slide 26

Slide 26 text

Web系の知識だけだと辛い
 UDP-IP/TCP-IP
 ICE
 DTLS
 SRTP
 SCTP
 Audio/Video
 Data
 ？ ？ ？ ？

Slide 27

Slide 27 text

本当はこう見えてるはず
 UDP-IP/TCP-IP
 ICE
 DTLS
 SRTP
 SCTP
 Audio/Video
 Data
 ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？

Slide 28

Slide 28 text

次世代のWebRTCのAPI達
 http://ortc.org/wp-content/uploads/2015/11/ortc.h tml

Slide 29

Slide 29 text

続：なぜ難しいのか？ 1. 世の中にあるノウハウが少ない
 • スタートアップ：リソース不足でテストも不足
 • 大きめの企業：新機能の実装に多忙
 • テストするにしても手動で頑張る
 
 2. Web/VoIP系の
 テストノウハウを転用しにくい
 
 3. テスト条件が非常に複雑


Slide 30

Slide 30 text

テスト条件の複雑さ • クライアント種別
 
 • OS 
 • ネットワーク
 
 • チャネルタイプ


Slide 31

Slide 31 text

テスト条件の複雑さ • クライアント種別
 
 • OS 
 • ネットワーク
 
 • チャネルタイプ
 総項目数は
 乗算で算出…
 まともにテストすると処理しきれない項目数になります。テスト技法を利用しても、それなりの数になります。


Slide 32

Slide 32 text

再掲：なぜ難しいのか？ 1. 世の中にあるノウハウが少ない
 • スタートアップ：リソース不足でテストも不足
 • 大きめの企業：新機能の実装に多忙
 • テストするにしても手動で頑張る
 
 2. Web/VoIP系の
 テストノウハウを転用しにくい
 
 3. テスト条件が非常に複雑
 ここまで、テストの難しさについて説明してきましたが、難しくてもテストできないわけではなありません。


Slide 33

Slide 33 text

SkyWay開発で得た知見を共有
 
 [1] WebRTCテストに必要な知識
 [2] 自動テストの実装例・デモ テストを作成するには、まずWebRTCの接続ロジックに関する最低限の理解が必要です。


Slide 34

Slide 34 text

■ 前提
 • AさんとBさんの2名で1:1のビデオチャット
 
 ■ 構成
 Webサーバ Aさん Bさん シグナリングサーバ
 ビデオチャット WebRTCのつながる仕組み

Slide 35

Slide 35 text

HTML/CSS/JS を取得 ■ 両者がWebサーバから
 必要な情報(HTML/CSS/JS)を取得
 WebRTCのつながる仕組み

Slide 36

Slide 36 text

■ 両者がシグナリングサーバへ接続し、
 自身が通信可能(応答可能）であることを伝える
 例：WebRTCの通信 できますよ WebRTCのつながる仕組み

Slide 37

Slide 37 text

Aさん Bさん ■ Aさんが「Bさんが応答可能であること」を知る
 通信可能な相手 を取得 WebRTCのつながる仕組み

Slide 38

Slide 38 text

■ AさんからBさんに発信する
 発信の際に、接続に必要な情報（自身のIPアドレス等）も送信 
 発信する 接続に必要な情報 （自身のIPアドレス等） も伝える Aさんの情報 が分かる WebRTCのつながる仕組み Aさん Bさん

Slide 39

Slide 39 text

■ Bさんが応答
 応答する 接続に必要な情報 （自身のIPアドレス等） も応答する Bさんの情報 が分かる WebRTCのつながる仕組み Aさん Bさん

Slide 40

Slide 40 text

■ お互いの情報が分かったので、両者で接続試行を開始
 ■ 疎通確認できれば、DTLS -> メディア送受信へ
 WebRTCのつながる仕組み （お互いに接続試行） 簡単なフローで説明してきましたが…


Slide 41

Slide 41 text

41 https://www.flickr.com/photos/quinnanya/5725134193/in/photolist-9HUNWe-b8jHcK-rSwrzt-atwgwq-bpPfNY-bApGtz-ecmxMj-9EGJHX-528Fwg-8dUZxf-4UC2WQ-6g9N7Y-9gBdk-aJHuGn-Liot-ecfS8F-fxRKP-aJHzkc-2GjZ4-4eW4uF-aPeYT2-6g5B7n-4Z8NVd-c5ajM b-9XczhB-9WrZtQ-b8jGWK-9YPUbX-mtwiS-9sbqhu-dKXwcs-bpPfk7-sL7JUy-pnYnKK-4Z4xZF-4Z8Nbq-89sth7-2nMrHh-dLkS1Z-4Z4yD8-4Z4yGv-4Z4yyx-4WFtU8-bk4C1S-b8jFHM-aEbapg-92VG51-aFSRzH-8hpoTY-e5KL4o 現実はもっと複雑

Slide 42

Slide 42 text

■ ICEは以下の順で動作
 1. STUNとTURNを利用し、
 通信可能なアドレス候補(ICE候補)を収集
 
 2. 収集したICE候補群を優先度順でソート
 
 3. SDPにICE候補群を設定して、通信相手と共有
 
 4. ICE候補群を利用して実際に接続試行
 “アドレス取得 -> 接続試行”にはICEを利用


Slide 43

Slide 43 text

■ NATやFirewallの多くの動作
 • デフォルトでは、内から外への通信のみが許可
 • 外から内への通信は
 事前に内から外への通信があった場合のみ許容
 
 ■ UDPホールパンチングは上記の動作を考慮し
 P2P接続を確立する技術
 補足：UDPだけでなくTCPも存在するが、ここでは省略 UDPホールパンチング


Slide 44

Slide 44 text

NAT NAT 右側NATにマッピング※が ないため疎通NG ※NAT前後のアドレスを 紐付ける情報のこと 続：UDPホールパンチング


Slide 45

Slide 45 text

NAT NAT 右側NATにマッピング※が ないため疎通NG ※NAT前後のアドレスを 紐付ける情報のこと 続：UDPホールパンチング
 マッピングできる！

Slide 46

Slide 46 text

NAT NAT 続：UDPホールパンチング
 Aさん側にマッピングが あるため疎通OK

Slide 47

Slide 47 text

NAT NAT 続：UDPホールパンチング
 Aさん側にマッピングが あるため疎通OK マッピングができる！

Slide 48

Slide 48 text

NAT NAT 両方に穴(ホール)が開いたので


Slide 49

Slide 49 text

NAT NAT 今回は右側NATにも マッピングがあり疎通OK ついに両者で疎通する！


Slide 50

Slide 50 text

成功可否はNATの特性に依存する
 • マッピング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent 
 • フィルタリング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent


Slide 51

Slide 51 text

まずはマッピング
 • マッピング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent 
 • フィルタリング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent


Slide 52

Slide 52 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 192.168.1.1 1.1.1.1 前提


Slide 53

Slide 53 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Endpoint Independent Mapping 192.168.1.1 1.1.1.1

Slide 54

Slide 54 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.200:80 Endpoint Independent Mapping 192.168.1.1 1.1.1.1 ？

Slide 55

Slide 55 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：1.1.1.1:12345 先：1.1.1.200:80 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.200:80 Endpoint Independent Mapping 192.168.1.1 1.1.1.1 通信相手のIPが異なっても、送信元アドレスは同一


Slide 56

Slide 56 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address Dependent Mapping 192.168.1.1 1.1.1.1 ここまでは一緒


Slide 57

Slide 57 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address Dependent Mapping 192.168.1.1 1.1.1.1 通信相手のIPが異なると・・・
 1.1.1.1 ？ 元：192.168.1.2:10000 先：1.1.1.200:80

Slide 58

Slide 58 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：1.1.1.1:54321 先：1.1.1.200:80 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.200:80 Address Dependent Mapping 192.168.1.1 1.1.1.1 通信相手のIPが異なると、送信元アドレスは異なる


Slide 59

Slide 59 text

NAT 1.1.1.100 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:8888 Address Dependent Mapping 192.168.1.1 1.1.1.1 では、通信相手のIPが同じでポートが異なる場合は…
 ？

Slide 60

Slide 60 text

NAT 1.1.1.100 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：1.1.1.1:12345 先：1.1.1.100:8888 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:8888 Address Dependent Mapping 192.168.1.1 1.1.1.1 NAT変換後の送信元アドレスは同一


Slide 61

Slide 61 text

NAT 1.1.1.100 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:8888 Address and Port Dependent Mapping 192.168.1.1 1.1.1.1 3種類目のマッピングの場合は？
 ？

Slide 62

Slide 62 text

NAT 1.1.1.100 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:8888 Address and Port Dependent Mapping 192.168.1.1 1.1.1.1 元：1.1.1.1:54321 先：1.1.1.100:8888 NAT変換後の送信元アドレスは異なる


Slide 63

Slide 63 text

63 続いてフィルタリング
 • マッピング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent 
 • フィルタリング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent


Slide 64

Slide 64 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 前提：当たり前の動作
 192.168.1.1 1.1.1.1 元：1.1.1.100:80 先：1.1.1.1:12345

Slide 65

Slide 65 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Endpoint Independent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.200:80 先：1.1.1.1:12345 異なるIPから届いたら？
 ？

Slide 66

Slide 66 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Endpoint Independent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.200:80 先：1.1.1.1:12345 そのまま通す！


Slide 67

Slide 67 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address Dependent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.200:80 先：1.1.1.1:12345 2種類目のフィルタリング動作だと？
 ？

Slide 68

Slide 68 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address Dependent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.200:80 先：1.1.1.1:12345 通さない！（IPアドレスに依存するので）


Slide 69

Slide 69 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address Dependent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.100:8888 先：1.1.1.1:12345 同じ送信先IPでも、異なるポートから返ってきたら？
 ？

Slide 70

Slide 70 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address Dependent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.100:8888 先：1.1.1.1:12345 通す！（IPアドレスが同じなので）


Slide 71

Slide 71 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address and Port Dependent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.100:8888 先：1.1.1.1:12345 ３種類目のNATの場合は？
 ？

Slide 72

Slide 72 text

NAT 1.1.1.100 1.1.1.200 192.168.1.2 元：1.1.1.1:12345 先：1.1.1.100:80 元：192.168.1.2:10000 先：1.1.1.100:80 Address and Port Dependent Filtering 192.168.1.1 1.1.1.1 元：1.1.1.100:8888 先：1.1.1.1:12345 通さない！（IPとポートの両方が同じでないため）


Slide 73

Slide 73 text

再掲：NATの振舞い
 • マッピング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent 
 • フィルタリング
 1. Endpoint independent 2. Address Dependent 3. Address and Port Dependent


Slide 74

Slide 74 text

参考： RFC3489(obsolete)でのNAT分類
 マッピング フィルタリング RFC3489 Endpoint Independent Endpoint Independent フルコーン Endpoint Independent Address Dependent 制限付きコーン Endpoint Independent Address and Port Dependent ポート制限付きコーン Address Dependent Endpoint Independent - Address Dependent Address Dependent - Address Dependent Address and Port Dependent - Address and Port Dependent Endpoint Independent - Address and Port Dependent Address Dependent - Address and Port Dependent Address and Port Dependent シンメトリック

Slide 75

Slide 75 text

P2PでのUDPホールパンチングの可否
 発信と着信のNAT分類 の組合せで決定 発信 着信

Slide 76

Slide 76 text

P2PでのUDPホールパンチングの可否


Slide 77

Slide 77 text

SkyWay開発で得た知見を共有
 
 [1] WebRTCテストに必要な知識
 [2] 自動テストの実装例・デモ

Slide 78

Slide 78 text

ということで WebRTCアプリケーションの 自動テストフレームワークを 作りました

Slide 79

Slide 79 text

• 複数のブラウザタイプでテストできるようにした – Chrome stable 対 Chrome stable – Chrome beta 対 Firefox Stable – などなど • 複数のNATタイプでテストできるようにした – EIMxEIF 対 APDMxAPDF – などなど(詳細後述) • (ある程度手軽に)環境構築からテスト実施まで自動化できる ようにした やったこと

Slide 80

Slide 80 text

やったこと(続) • ブラウザ1とブラウザ2の間に入るNATのタイプまで含めてテ ストするにはローカル環境(vagrantなど)だと無理 – AWS VPC内に互いに通信できない複数のprivate subnetを 作成し、その中でテストする

Slide 81

Slide 81 text

Intranet1 Intranet2 Virtual Internet アーキテクチャ概要 Virtual private cloud Private Subnet TURN server Signaling server WebApp server 特製 NAT 特製 NAT Ubuntu14.04 (with Chrome, Firefox, Selenium) Ubuntu14.04 (with Chrome, Firefox, Selenium) Ubuntu Ubuntu

Slide 82

Slide 82 text

DataChannel のテスト テストシナリオ例1 Signaling server Intranet1 Ubuntu ブラウザ Intranet2 Ubuntu ブラウザ Virtual Internet

Slide 83

Slide 83 text

Signaling server Intranet1 Ubuntu ブラウザ Intranet2 Ubuntu ブラウザ Virtual Internet MediaChannel のテスト テストシナリオ例2

Slide 84

Slide 84 text

・ブラウザ種別 ・ Chrome Stable, Chrome Beta, Chrome Unstable ・ Firefox Stable (, Firefox Unstable) ・NATタイプ ・RFC4787上の定義では9種類 ・iptablesでは設定不可なタイプもあるので 新しく作った ・4 * 4 * 9 * 9 = 1296 多い…時間かかる … Browser x Browser x NAT type x NAT type

Slide 85

Slide 85 text

Intranet1 Intranet2 Virtual Internet アーキテクチャ概要 (再掲) Virtual private cloud Private Subnet TURN server Signaling server WebApp server 特製 NAT 特製 NAT Ubuntu14.04 (with Chrome, Firefox, Selenium) Ubuntu14.04 (with Chrome, Firefox, Selenium) Ubuntu Ubuntu

Slide 86

Slide 86 text

Intranet2 Virtual Internet アーキテクチャ概要 (フルフルセットアップ版) Private Subnet TURN server Signaling server WebApp server 特製 NAT type 1 Ubuntu14.04 16台 特製 NAT type2 . . . Ubuntu14.04 16台 . . . 特製 NAT type9 . . . . . . . . . Intranet1 特製 NAT type 1 特製 NAT type2 特製 NAT type9 . . . . . . . . .

Slide 87

Slide 87 text

テスト結果画面 http://status.skyway.io

Slide 88

Slide 88 text

・デスクトップなしの環境でブラウザをSeleniumで動かしたい ・ Xvfb ・ ブラウザオプション ・ 仮想のカメラやマイク ・ use-fake-device-for-media-stream (chrome) ・ media.navigator.streams.fake (firefox) ・ ダイアログなど出ないように ・ use-fake-ui-for-media-stream (chrome) ・ media.navigator.permission.disabled (firefox) 実装上の工夫点1

Slide 89

Slide 89 text

・2つの別々のマシンで同時にseleniumのテストを実行したい ・ offerer側とanswerer側のテストシナリオをそれぞれ用意、 CIサーバからいっぺんにキック (sshで入ってシェル実行) ・ answerer側をちょっと先に起動して待たせておく ・ ssh先のサーバでsudoしたり、、、 -> シェル職人 実装上の工夫点2

Slide 90

Slide 90 text

・ seleniumのwebdriverの実装なのか、firefoxは素のままだと console.logが取れない… ・ FireBug + ConsoleExport を追加してそれ経由で取得 ・ firefoxの新し目のバージョンだと署名されていない プラグインが動かない(ブラウザオプションなども効かない) ・ 開発用のバージョンもそのうち出るらしいが、まだ未確認 実装上の工夫点3

Slide 91

Slide 91 text

・ 映像が本当に流れているかの確認 ・ つながったっぽいが、映像が真っ黒のままの場合はfailさせたい ・ videoタグから一定間隔でデータをcanvasにコピーして、 各ピクセルの平均値が一定のレベル以上明るいか判定 実装上の工夫点4 Xvfbで上げたchromeから何かが返ってきている図(右)

Slide 92

Slide 92 text

ご清聴ありがとうございました。