WebRTCアプリケーションのテストの課題・解決方法について / Problems and Solutions for WebRTC Testing

WebRTC Conference Japanの講演資料です。

Transcript

1. WebRTCアプリケーションの
 テストの課題・解決方法について 2016/2/17(Wed) @ WebRTC Conference Japan 岩瀬 義昌(NTTコミュニケーションズ株式会社) 瀧川 顕謙(株式会社 ネフロック)
2. ▪名前
 岩瀬 義昌/ @iwashi86
 ▪仕事
 株式会社NTTコミュンケーションズ
 SkyWayの開発・運用
 ▪名前
 瀧川 顕謙/ @kenkenkenken8 ▪仕事
 株式会社ネフロック CTO

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

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

5. 当初の検証は良好！
6. ケース１: 突然 利用不可に
7. 実例：getUserMediaがある日突然 動かない
8. ケース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
9. ケース2: 多様な通信条件 ラップトップ x Wifi スマフォ x LTE テザリング x タブレット インターネット WebRTCのクライアントの種類・NW条件は本当に多様であり、ある環境ではUX低下という事象もありえます。

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

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

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

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

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

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

16. VoIP側からの視点
17. VoIPテストの例 オンプレミスで実機テスト SIPサーバ/ IP-PBX

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

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

20. 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
21. 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 独自シグナリング
22. 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プラットフォーマからすると

23. こんな風に見えてます
 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ヶ月で
 アップデート 独自シグナリング
24. Web側からの視点
25. WebRTCのプロトコルスタック
 UDP-IP/TCP-IP
 ICE
 DTLS
 SRTP
 SCTP
 Audio/Video
 Data

26. Web系の知識だけだと辛い
 UDP-IP/TCP-IP
 ICE
 DTLS
 SRTP
 SCTP
 Audio/Video
 Data
 ？ ？ ？ ？
27. 本当はこう見えてるはず
 UDP-IP/TCP-IP
 ICE
 DTLS
 SRTP
 SCTP
 Audio/Video
 Data
 ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？
28. 次世代のWebRTCのAPI達
 http://ortc.org/wp-content/uploads/2015/11/ortc.h tml
29. 続：なぜ難しいのか？ 1. 世の中にあるノウハウが少ない
 • スタートアップ：リソース不足でテストも不足
 • 大きめの企業：新機能の実装に多忙
 • テストするにしても手動で頑張る
 
 2. Web/VoIP系の
 テストノウハウを転用しにくい
 
 3. テスト条件が非常に複雑

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

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

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

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

34. ▪ 前提
 • AさんとBさんの2名で1:1のビデオチャット
 
 ▪ 構成
 Webサーバ Aさん Bさん シグナリングサーバ
 ビデオチャット WebRTCのつながる仕組み
35. HTML/CSS/JS を取得 ▪ 両者がWebサーバから
 必要な情報(HTML/CSS/JS)を取得
 WebRTCのつながる仕組み
36. ▪ 両者がシグナリングサーバへ接続し、
 自身が通信可能(応答可能）であることを伝える
 例：WebRTCの通信 できますよ WebRTCのつながる仕組み
37. Aさん Bさん ▪ Aさんが「Bさんが応答可能であること」を知る
 通信可能な相手 を取得 WebRTCのつながる仕組み
38. ▪ AさんからBさんに発信する
 発信の際に、接続に必要な情報（自身のIPアドレス等）も送信 
 発信する 接続に必要な情報 （自身のIPアドレス等） も伝える Aさんの情報 が分かる WebRTCのつながる仕組み Aさん Bさん
39. ▪ Bさんが応答
 応答する 接続に必要な情報 （自身のIPアドレス等） も応答する Bさんの情報 が分かる WebRTCのつながる仕組み Aさん Bさん
40. ▪ お互いの情報が分かったので、両者で接続試行を開始
 ▪ 疎通確認できれば、DTLS -> メディア送受信へ
 WebRTCのつながる仕組み （お互いに接続試行） 簡単なフローで説明してきましたが…

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

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

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

45. NAT NAT 右側NATにマッピング※が ないため疎通NG ※NAT前後のアドレスを 紐付ける情報のこと 続：UDPホールパンチング
 マッピングできる！
46. NAT NAT 続：UDPホールパンチング
 Aさん側にマッピングが あるため疎通OK
47. NAT NAT 続：UDPホールパンチング
 Aさん側にマッピングが あるため疎通OK マッピングができる！
48. NAT NAT 両方に穴(ホール)が開いたので

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

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

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

52. NAT 1.1.1.100 1.1.1.200 192.168.1.2 192.168.1.1 1.1.1.1 前提

53. 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
54. 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 ？
55. 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が異なっても、送信元アドレスは同一

56. 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 ここまでは一緒

57. 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
58. 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が異なると、送信元アドレスは異なる

59. 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が同じでポートが異なる場合は…
 ？
60. 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変換後の送信元アドレスは同一

61. 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種類目のマッピングの場合は？
 ？
62. 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変換後の送信元アドレスは異なる

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

64. 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
65. 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から届いたら？
 ？
66. 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 そのまま通す！

67. 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種類目のフィルタリング動作だと？
 ？
68. 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アドレスに依存するので）

69. 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でも、異なるポートから返ってきたら？
 ？
70. 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アドレスが同じなので）

71. 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の場合は？
 ？
72. 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とポートの両方が同じでないため）

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

74. 参考： 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 シンメトリック
75. P2PでのUDPホールパンチングの可否
 発信と着信のNAT分類 の組合せで決定 発信 着信
76. P2PでのUDPホールパンチングの可否

77. SkyWay開発で得た知見を共有
 
 [1] WebRTCテストに必要な知識
 [2] 自動テストの実装例・デモ
78. ということで WebRTCアプリケーションの 自動テストフレームワークを 作りました
79. • 複数のブラウザタイプでテストできるようにした – Chrome stable 対 Chrome stable – Chrome beta 対 Firefox Stable – などなど • 複数のNATタイプでテストできるようにした – EIMxEIF 対 APDMxAPDF – などなど(詳細後述) • (ある程度手軽に)環境構築からテスト実施まで自動化できる ようにした やったこと
80. やったこと(続) • ブラウザ1とブラウザ2の間に入るNATのタイプまで含めてテ ストするにはローカル環境(vagrantなど)だと無理 – AWS VPC内に互いに通信できない複数のprivate subnetを 作成し、その中でテストする
81. 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
82. DataChannel のテスト テストシナリオ例1 Signaling server Intranet1 Ubuntu ブラウザ Intranet2 Ubuntu ブラウザ Virtual Internet
83. Signaling server Intranet1 Ubuntu ブラウザ Intranet2 Ubuntu ブラウザ Virtual Internet MediaChannel のテスト テストシナリオ例2
84. ・ブラウザ種別 ・ 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
85. 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
86. 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 . . . . . . . . .
87. テスト結果画面 http://status.skyway.io
88. ・デスクトップなしの環境でブラウザを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
89. ・2つの別々のマシンで同時にseleniumのテストを実行したい ・ offerer側とanswerer側のテストシナリオをそれぞれ用意、 CIサーバからいっぺんにキック (sshで入ってシェル実行) ・ answerer側をちょっと先に起動して待たせておく ・ ssh先のサーバでsudoしたり、、、 -> シェル職人 実装上の工夫点2
90. ・ seleniumのwebdriverの実装なのか、firefoxは素のままだと console.logが取れない… ・ FireBug + ConsoleExport を追加してそれ経由で取得 ・ firefoxの新し目のバージョンだと署名されていない プラグインが動かない(ブラウザオプションなども効かない) ・ 開発用のバージョンもそのうち出るらしいが、まだ未確認 実装上の工夫点3
91. ・ 映像が本当に流れているかの確認 ・ つながったっぽいが、映像が真っ黒のままの場合はfailさせたい ・ videoタグから一定間隔でデータをcanvasにコピーして、 各ピクセルの平均値が一定のレベル以上明るいか判定 実装上の工夫点4 Xvfbで上げたchromeから何かが返ってきている図(右)
92. ご清聴ありがとうございました。