細かくて伝わらないWebRTC(APIとか) / Tip for WebRTC (APIs)

NTT Tech Conference #3(https://ntt-developers.github.io/ntt-tech-conference/03/) にて講演した資料です。

訂正: P.37-39 の見出しは、"DTLSの上"ではなく"SCTPの上"が正解です。

Transcript

1. Copyright © NTT Communications Corporation. All rights reserved. 細かくて伝わらない WebRTC (APIとか) NTT Tech Conference #3 NTTコミュニケーションズ 岩瀬 義昌 / @iwashi86 2018.8.31
2. ・岩瀬 義昌 / @iwashi86 ・WebRTC Platformである 　SkyWay の中の人 ・Fukabori.fm(Podcast)主催
3. 本題
4. 1. WebRTCの概要 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)
6. Web IPネットワーク上の Real Time 時差がほとんどない Communication 通信 / 意思疎通
7. 1876年にベルが 電話を発明。 以降、電話会社が リアルタイム・ コミュニケーションを 独占。 www.flickr.com/photos/mattb_tv/2550476978
8. 2000年前後に Skypeが登場 スーパーハッカーが 独占を壊した https://www.flickr.com/photos/kenu/624579777/in/photolist-Xc8NR-qXX93-cyDfJ7-66Nbn4-rhywsb-7wru3H-7gZauJ-7E9nzF-cev1KW-9ytybn-9M1Vwm-2VCUGX-qDGRd-ukDvx-2xDnyt-cFkYEs-9ywzcG-qHtcd-dWMykv-N1vYN-6fB66u-9ytzq2-9ytz4c-ngbJaR-9ePue6-nxhYB5-dyawSh-9ywyjC-wneuN-8qhoPU-6wJvqW-oLSPwJ-ngd5iK-byjZk3-iQqiRU-8192wy-9ywAsJ-6nWiSv-oLSsTM-5HApmZ-arfyAZ-9f1q9a-6e1bMU-9LY7nM-f211u9-p4iTzE-p4iTDC-a1jo2Z-733g4f-cVTP1E
9. “リアルタイム・コミュニケーションの民主化” 2011年にWebRTCが発表され、 すべてのソフトウェアエンジニアが リアルタイム・コミュニケーションを 扱えるようになった www.flickr.com/photos/tjflex/57210112
10. WebRTCの特徴 x 3
11. 特徴1　通話と通信、2つの機能 a. 意思疎通(=ビデオ/音声通話) b. 通信(＝データ通信)
12. 特徴2　マルチプラットフォーム iOS, Android, Webブラウザで 利用できる (Raspberry Piでも!)
13. WebRTCの特徴3　シンプルなユーザ体験 Webサイトやアプリの中に 簡単に組み込める (SkypeやLINE等の他社アプリの インストールや起動が不要)
14. WebRTCを使うと…
15. ユースケースたくさん！ (https://webrtc.ecl.ntt.com/usecase/)
16. ただし本気で使うのは ちょっとめんどくさい
17. 宣伝: だから簡単に使えるSkyWay
18. 宣伝2: x86_64(Linux/Win) + ARMも
19. 1. WebRTCの概要 <--- 今ここ 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)
20. ここから難易度が 急激に上がります (上級向けセッションのため)
21. 1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)
22. 1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)
23. ChromeのaddIceCandidate ・こいつが意外に厄介
24. addIceCandidateの前提 ・addIceCandidateは 　setRemoteDescription済み 　じゃないと動かない ・なぜか？
25. RTCIceCandidateは SDP に紐づくから
26. Chromiumのソースコードより
27. RemoteSDPが無い場合は Falseを返してエラー処理へ ちなみに… 拡大すると…
28. $ cat chrome_debug.log | grep "AddIceCandidate” [2208:32027:0830/140419.827743: ERROR:peerconnection.cc(2940)] AddIceCandidate: ICE candidates can't be added without any remote session description. $ open /Applications/Google\ Chrome.app --args --enable-logging --args --v=1 しておくと、 /Users/XXX/Library/Application Support/Google/Chrome/chrome_debug.log が出力されるので、そこで見れる デバッグログからも見れる
29. addIceCandidateはなぜ厄介か？ ・addIceCandidate は Promiseを返す ・つまり 　pc.addIceCandidate() 　 　.then() // Resolve:成功 　.catch() // Reject:失敗
30. addIceCandidateはなぜ厄介か？ ・addIceCandidate は Promiseを返す ・つまり 　pc.addIceCandidate() 　 　.then() // Resolve:成功 　.catch() // Reject:失敗 　問題は「失敗」したとき
31. addIceCandidateはなぜ厄介か？ ・失敗したなら、 　変に状態を保持せずに 　全部忘れてくれるのを期待 ・現実は甘くない 　⇒ Rejectでも状態を覚えている
32. すなわち pc.addIceCandidate() 　 　.then() 　.catch() // こっちのルート の後に pc.setRemoteDescription(sdp) すると、ICEが疎通してメディアも通る （ちなみに、Firefoxは通らないので正しい。 　この実装に依存すると、一方だけ動く辛い戦いに）
33. 次
34. みんな大好きDataChannel ・おさらい
35. みんな大好きDataChannel ・おさらい 　pc.createDataChannel(“hoge”) 　=> onnegotiationneeded が発火 　=> pc.createOffer() 　 　すると、m=applicationを含む 　SDPが誕生する
36. プロトコル観点からいくと ・DataChannelはDTLSとSCTPの 　プロトコルの上にあると言われる 　 引用: https://hpbn.co/webrtc/
37. DTLSの上にもう1段ある => DCEP ・DCEP 　= Data Channel Establishment Protocol
38. DTLSの上にもう1段ある => DCEP ・DCEP 　= Data Channel Establishment Protocol ・軽量ネゴシエーションプロトコル 　・2 Way Handshake 　・OPEN -> ACK だけ 　
39. DTLSの上にもう1段ある => DCEP ・DCEP 　= Data Channel Establishment Protocol ・軽量ネゴシエーションプロトコル 　・2 Way Handshake 　・OPEN -> ACK だけ 　・DataChannelのネゴシエーションだけ 　　・DTLS-SRTPみたいな感じで 　　　実際には最初だけ使われる 　　　
40. 2つ目のDataChannel ・createDataChannelは、 　DataChannel確立後にも呼び出し可能 　(用途の違うDataChannelを複数作れる)
41. 2つ目のDataChannel ・createDataChannelは、 　DataChannel確立後にも呼び出し可能 　(用途の違うDataChannelを複数作れる) ・ただし、その場合 SDP の　 　Renegotiationは不要 　なぜか？
42. SDPに変更があるかが全て ・SDP的には確立するDataChannelが 　いくつ増えようが、交渉済みのSDPの 　m=applicationのブロックに変更がないから
43. SDPに変更があるかが全て ・SDP的には確立するDataChannelが 　いくつ増えようが、交渉済みのSDPの 　m=applicationのブロックに変更がないから ・JSEPのI-Dにも規定されている ”All data channels on a given PeerConnection share the same SCTP/DTLS association and therefore the same m= section, so subsequent creation of data channels does not have any impact on the JSEP state” 引用: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4.1.5 ・無駄に onnegotiationneeded を期待しないこと
44. 1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)
45. IPv6 の世界はすぐそこに ・SkyWayは国内だけでなく 　海外でも利用されている => IPv6 いる！
46. IPv6 の世界はすぐそこに ・SkyWayは国内だけでなく 　海外でも利用されている => IPv6 いる！ ・日本だとまだ少ないが 　海外CareerはIPv6配布オンリーが存在
47. IPv6 の世界はすぐそこに ・SkyWayは国内だけでなく 　海外でも利用されている => IPv6 いる！ ・日本だとまだ少ないが 　海外CareerはIPv6配布オンリーが存在 ・AppleもIPv6対応してないと 　アプリの審査で落としている 　・ただし、DNS64 + NAT64 対応でOK
48. https://www.nic.ad.jp/ja/newsletter/No64/0800.html DNS64 + NAT64 とは
49. https://www.nic.ad.jp/ja/newsletter/No64/0800.html DNS64 + NAT64 とは
50. DNS64 + NAT64 の欠点 ・DNS と密結合している仕組み 　・Webブラウジング / EメールはOK
51. DNS64 + NAT64 の欠点 ・DNS と密結合している仕組み 　・Webブラウジング / EメールはOK ・WebRTCはそうじゃない世界 　・SDPにのってくる 　　トランスポートアドレスは 　　FQDNじゃない(DNSを引かない) a=candidate:1 1 UDP 2130706431 2402:c800:略:fc13:1c8b 実例:
52. DNS64 + NAT64 の欠点 ・DNS と密結合している仕組み 　・Webブラウジング / EメールはOK ・WebRTCはそうじゃない世界 　・SDPにのってくる 　　トランスポートアドレスは 　　FQDNじゃない(DNSを引かない) 　⇒ DNS64 + NAT64 と WebRTC は 　　 究極的に相性が良いわけじゃない
53. ところで Android ・v6(onlyを配布するCareer) - v4(任意) で 　ICEでつなげてみると何が起こるか？
54. ところで Android ・v6(onlyを配布するCareer) - v4(任意) で 　ICEでつなげてみると何が起こるか？ ・結論から言うと、ICEは確立 　chrome://webrtc-internalsは？
55. なんとinternals上はv4しか見えない mask mask
56. 実は v6 only を端末に 配布してくるキャリアが保 持するv4アドレス なんとinternals上はv4しか見えない mask mask
57. 何が起きているのか？ ・v6のAndroid端末に付与される 　IPアドレスを確認すると…
58. 何が起きているのか？ ・v6のAndroid端末に付与される 　IPアドレスを確認すると… デュアルスタックっぽいけど、ちょっと違う mask
59. 答えは 464XLAT https://tools.ietf.org/html/rfc6877
60. 答えは 464XLAT Android OSの中に CLATデーモンがある https://tools.ietf.org/html/rfc6877
61. v4 STUNサーバがあると… STUN https://tools.ietf.org/html/rfc6877
62. STUN v4 STUNサーバがあると… https://tools.ietf.org/html/rfc6877
63. STUN v4 STUNサーバがあると… https://tools.ietf.org/html/rfc6877
64. STUN v4 STUNサーバがあると… mask https://tools.ietf.org/html/rfc6877
65. 1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)
66. WebRTC Next Version! ・仕様策定者の間で 　ユースケースを洗い出している https://docs.google.com/document/d/1valj1gBZ2eMhAHSKOhFOWIRymnntWi7xKUeESvN4VxI/edit
67. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf WebRTC NVのAPIはどうなる？
68. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf WebRTC NVのAPIはどうなる？
69. 様々な検討要素(components)がある https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf
70. ICEが好きなのでICEについて語る https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf
71. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜
72. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜
73. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜
74. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜
75. https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜
76. 参考: https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf Pros / Cons から落とし所を探る ・WebRTC-ICE 　・SDPおよびTransportを分離する 　・DTLS/SRTP じゃなくて QUIC も対応
77. 参考: https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf Pros / Cons から落とし所を探る ・WebRTC-ICE 　・SDPおよびTransportを分離する 　・DTLS/SRTP じゃなくて QUIC も対応 ・ORTC 　・Forkingをサポートしているけど、 　　まぁ…見なかったことにする
78. 参考: https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf Pros / Cons から落とし所を探る ・WebRTC-ICE 　・SDPおよびTransportを分離する 　・DTLS/SRTP じゃなくて QUIC も対応 ・ORTC 　・Forkingをサポートしているけど、 　　まぁ…見なかったことにする ・FlexibleICE / FlexICE 　・UDPホールパンチングも制御できるように 　・実装はかなり大変になるが、デフォルト動作も
79. 参考: https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf Pros / Cons から落とし所を探る ・WebRTC-ICE 　・SDPおよびTransportを分離する 　・DTLS/SRTP じゃなくて QUIC も対応 ・ORTC 　・Forkingをサポートしているけど、 　　まぁ…見なかったことにする ・FlexibleICE / FlexICE 　・UDPホールパンチングも制御できるように 　・実装はかなり大変になるが、デフォルト動作も ・SLICE 　・ICE自体を全部実装 => 常識的に考えて地獄 　・普通の開発者はライブラリを使う
80. 参考: https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf Pros / Cons から落とし所を探る ・WebRTC-ICE 　・SDPおよびTransportを分離する 　・DTLS/SRTP じゃなくて QUIC も対応 ・ORTC 　・Forkingをサポートしているけど、 　　まぁ…見なかったことにする ・FlexibleICE / FlexICE 　・UDPホールパンチングも制御できるように 　・実装はかなり大変になるが、デフォルト動作も ・SLICE 　・ICE自体を全部実装 => 常識的に考えて地獄 　・普通の開発者はライブラリを使う
81. ・今は隠蔽されているLow Level APIの解放 　・ICEのPriorityの任意設定 　・ICEの接続維持の間隔調整　　とか https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf
82. 今後の流れ 資料と議事録は出るので それを追うだけでも未来が見える https://www.w3.org/2018/10/TPAC/
83. さらにその未来 (IETF) 引用: https://www.slideshare.net/AmirZ/webrtc-standards-implementation-qa-the-future-is-now2
84. アーキテクチャの再設計へ… ・何年かかるか分からないレベルの話 ・興味あれば次にIETFをWatch 　(IETFは誰でもRemote参加できる) https://tools.ietf.org/html/draft-jennings-dispatch-new-media-01
85. まとめ
86. 1. WebRTCの概要 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話) 本日お話したこと おしまい