Tweet
Tweet

Slide 1

Slide 1 text

Copyright © NTT Communications Corporation. All rights reserved. 細かくて伝わらない WebRTC (APIとか) NTT Tech Conference #3 NTTコミュニケーションズ 岩瀬 義昌 / @iwashi86 2018.8.31

Slide 2

Slide 2 text

・岩瀬 義昌 / @iwashi86 ・WebRTC Platformである 　SkyWay の中の人 ・Fukabori.fm(Podcast)主催

Slide 3

Slide 3 text

本題

Slide 4

Slide 4 text

1. WebRTCの概要 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Web IPネットワーク上の Real Time 時差がほとんどない Communication 通信 / 意思疎通

Slide 7

Slide 7 text

1876年にベルが 電話を発明。 以降、電話会社が リアルタイム・ コミュニケーションを 独占。 www.flickr.com/photos/mattb_tv/2550476978

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

“リアルタイム・コミュニケーションの民主化” 2011年にWebRTCが発表され、 すべてのソフトウェアエンジニアが リアルタイム・コミュニケーションを 扱えるようになった www.flickr.com/photos/tjflex/57210112

Slide 10

Slide 10 text

WebRTCの特徴 x 3

Slide 11

Slide 11 text

特徴1　通話と通信、2つの機能 a. 意思疎通(=ビデオ/音声通話) b. 通信(＝データ通信)

Slide 12

Slide 12 text

特徴2　マルチプラットフォーム iOS, Android, Webブラウザで 利用できる (Raspberry Piでも!)

Slide 13

Slide 13 text

WebRTCの特徴3　シンプルなユーザ体験 Webサイトやアプリの中に 簡単に組み込める (SkypeやLINE等の他社アプリの インストールや起動が不要)

Slide 14

Slide 14 text

WebRTCを使うと…

Slide 15

Slide 15 text

ユースケースたくさん！ (https://webrtc.ecl.ntt.com/usecase/)

Slide 16

Slide 16 text

ただし本気で使うのは ちょっとめんどくさい

Slide 17

Slide 17 text

宣伝: だから簡単に使えるSkyWay

Slide 18

Slide 18 text

宣伝2: x86_64(Linux/Win) + ARMも

Slide 19

Slide 19 text

1. WebRTCの概要 <--- 今ここ 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)

Slide 20

Slide 20 text

ここから難易度が 急激に上がります (上級向けセッションのため)

Slide 21

Slide 21 text

1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)

Slide 22

Slide 22 text

1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)

Slide 23

Slide 23 text

ChromeのaddIceCandidate ・こいつが意外に厄介

Slide 24

Slide 24 text

addIceCandidateの前提 ・addIceCandidateは 　setRemoteDescription済み 　じゃないと動かない ・なぜか？

Slide 25

Slide 25 text

RTCIceCandidateは SDP に紐づくから

Slide 26

Slide 26 text

Chromiumのソースコードより

Slide 27

Slide 27 text

RemoteSDPが無い場合は Falseを返してエラー処理へ ちなみに… 拡大すると…

Slide 28

Slide 28 text

$ 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 が出力されるので、そこで見れる デバッグログからも見れる

Slide 29

Slide 29 text

addIceCandidateはなぜ厄介か？ ・addIceCandidate は Promiseを返す ・つまり 　pc.addIceCandidate() 　 　.then() // Resolve:成功 　.catch() // Reject:失敗

Slide 30

Slide 30 text

addIceCandidateはなぜ厄介か？ ・addIceCandidate は Promiseを返す ・つまり 　pc.addIceCandidate() 　 　.then() // Resolve:成功 　.catch() // Reject:失敗 　問題は「失敗」したとき

Slide 31

Slide 31 text

addIceCandidateはなぜ厄介か？ ・失敗したなら、 　変に状態を保持せずに 　全部忘れてくれるのを期待 ・現実は甘くない 　⇒ Rejectでも状態を覚えている

Slide 32

Slide 32 text

すなわち pc.addIceCandidate() 　 　.then() 　.catch() // こっちのルート の後に pc.setRemoteDescription(sdp) すると、ICEが疎通してメディアも通る （ちなみに、Firefoxは通らないので正しい。 　この実装に依存すると、一方だけ動く辛い戦いに）

Slide 33

Slide 33 text

次

Slide 34

Slide 34 text

みんな大好きDataChannel ・おさらい

Slide 35

Slide 35 text

みんな大好きDataChannel ・おさらい 　pc.createDataChannel(“hoge”) 　=> onnegotiationneeded が発火 　=> pc.createOffer() 　 　すると、m=applicationを含む 　SDPが誕生する

Slide 36

Slide 36 text

プロトコル観点からいくと ・DataChannelはDTLSとSCTPの 　プロトコルの上にあると言われる 　 引用: https://hpbn.co/webrtc/

Slide 37

Slide 37 text

DTLSの上にもう1段ある => DCEP ・DCEP 　= Data Channel Establishment Protocol

Slide 38

Slide 38 text

DTLSの上にもう1段ある => DCEP ・DCEP 　= Data Channel Establishment Protocol ・軽量ネゴシエーションプロトコル 　・2 Way Handshake 　・OPEN -> ACK だけ 　

Slide 39

Slide 39 text

DTLSの上にもう1段ある => DCEP ・DCEP 　= Data Channel Establishment Protocol ・軽量ネゴシエーションプロトコル 　・2 Way Handshake 　・OPEN -> ACK だけ 　・DataChannelのネゴシエーションだけ 　　・DTLS-SRTPみたいな感じで 　　　実際には最初だけ使われる 　　　

Slide 40

Slide 40 text

2つ目のDataChannel ・createDataChannelは、 　DataChannel確立後にも呼び出し可能 　(用途の違うDataChannelを複数作れる)

Slide 41

Slide 41 text

2つ目のDataChannel ・createDataChannelは、 　DataChannel確立後にも呼び出し可能 　(用途の違うDataChannelを複数作れる) ・ただし、その場合 SDP の　 　Renegotiationは不要 　なぜか？

Slide 42

Slide 42 text

SDPに変更があるかが全て ・SDP的には確立するDataChannelが 　いくつ増えようが、交渉済みのSDPの 　m=applicationのブロックに変更がないから

Slide 43

Slide 43 text

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 を期待しないこと

Slide 44

Slide 44 text

1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)

Slide 45

Slide 45 text

IPv6 の世界はすぐそこに ・SkyWayは国内だけでなく 　海外でも利用されている => IPv6 いる！

Slide 46

Slide 46 text

IPv6 の世界はすぐそこに ・SkyWayは国内だけでなく 　海外でも利用されている => IPv6 いる！ ・日本だとまだ少ないが 　海外CareerはIPv6配布オンリーが存在

Slide 47

Slide 47 text

IPv6 の世界はすぐそこに ・SkyWayは国内だけでなく 　海外でも利用されている => IPv6 いる！ ・日本だとまだ少ないが 　海外CareerはIPv6配布オンリーが存在 ・AppleもIPv6対応してないと 　アプリの審査で落としている 　・ただし、DNS64 + NAT64 対応でOK

Slide 48

Slide 48 text

https://www.nic.ad.jp/ja/newsletter/No64/0800.html DNS64 + NAT64 とは

Slide 49

Slide 49 text

https://www.nic.ad.jp/ja/newsletter/No64/0800.html DNS64 + NAT64 とは

Slide 50

Slide 50 text

DNS64 + NAT64 の欠点 ・DNS と密結合している仕組み 　・Webブラウジング / EメールはOK

Slide 51

Slide 51 text

DNS64 + NAT64 の欠点 ・DNS と密結合している仕組み 　・Webブラウジング / EメールはOK ・WebRTCはそうじゃない世界 　・SDPにのってくる 　　トランスポートアドレスは 　　FQDNじゃない(DNSを引かない) a=candidate:1 1 UDP 2130706431 2402:c800:略:fc13:1c8b 実例:

Slide 52

Slide 52 text

DNS64 + NAT64 の欠点 ・DNS と密結合している仕組み 　・Webブラウジング / EメールはOK ・WebRTCはそうじゃない世界 　・SDPにのってくる 　　トランスポートアドレスは 　　FQDNじゃない(DNSを引かない) 　⇒ DNS64 + NAT64 と WebRTC は 　　 究極的に相性が良いわけじゃない

Slide 53

Slide 53 text

ところで Android ・v6(onlyを配布するCareer) - v4(任意) で 　ICEでつなげてみると何が起こるか？

Slide 54

Slide 54 text

ところで Android ・v6(onlyを配布するCareer) - v4(任意) で 　ICEでつなげてみると何が起こるか？ ・結論から言うと、ICEは確立 　chrome://webrtc-internalsは？

Slide 55

Slide 55 text

なんとinternals上はv4しか見えない mask mask

Slide 56

Slide 56 text

実は v6 only を端末に 配布してくるキャリアが保 持するv4アドレス なんとinternals上はv4しか見えない mask mask

Slide 57

Slide 57 text

何が起きているのか？ ・v6のAndroid端末に付与される 　IPアドレスを確認すると…

Slide 58

Slide 58 text

何が起きているのか？ ・v6のAndroid端末に付与される 　IPアドレスを確認すると… デュアルスタックっぽいけど、ちょっと違う mask

Slide 59

Slide 59 text

答えは 464XLAT https://tools.ietf.org/html/rfc6877

Slide 60

Slide 60 text

答えは 464XLAT Android OSの中に CLATデーモンがある https://tools.ietf.org/html/rfc6877

Slide 61

Slide 61 text

v4 STUNサーバがあると… STUN https://tools.ietf.org/html/rfc6877

Slide 62

Slide 62 text

STUN v4 STUNサーバがあると… https://tools.ietf.org/html/rfc6877

Slide 63

Slide 63 text

STUN v4 STUNサーバがあると… https://tools.ietf.org/html/rfc6877

Slide 64

Slide 64 text

STUN v4 STUNサーバがあると… mask https://tools.ietf.org/html/rfc6877

Slide 65

Slide 65 text

1. WebRTCの概要 <----- 超えられない壁 -----> 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話)

Slide 66

Slide 66 text

WebRTC Next Version! ・仕様策定者の間で 　ユースケースを洗い出している https://docs.google.com/document/d/1valj1gBZ2eMhAHSKOhFOWIRymnntWi7xKUeESvN4VxI/edit

Slide 67

Slide 67 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf WebRTC NVのAPIはどうなる？

Slide 68

Slide 68 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf WebRTC NVのAPIはどうなる？

Slide 69

Slide 69 text

様々な検討要素(components)がある https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf

Slide 70

Slide 70 text

ICEが好きなのでICEについて語る https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf

Slide 71

Slide 71 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜

Slide 72

Slide 72 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜

Slide 73

Slide 73 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜

Slide 74

Slide 74 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜

Slide 75

Slide 75 text

https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf ICEの進化(?)の系譜

Slide 76

Slide 76 text

参考: 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 も対応

Slide 77

Slide 77 text

参考: 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をサポートしているけど、 　　まぁ…見なかったことにする

Slide 78

Slide 78 text

参考: 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ホールパンチングも制御できるように 　・実装はかなり大変になるが、デフォルト動作も

Slide 79

Slide 79 text

参考: 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自体を全部実装 => 常識的に考えて地獄 　・普通の開発者はライブラリを使う

Slide 80

Slide 80 text

参考: 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自体を全部実装 => 常識的に考えて地獄 　・普通の開発者はライブラリを使う

Slide 81

Slide 81 text

・今は隠蔽されているLow Level APIの解放 　・ICEのPriorityの任意設定 　・ICEの接続維持の間隔調整　　とか https://www.w3.org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19.pdf

Slide 82

Slide 82 text

今後の流れ 資料と議事録は出るので それを追うだけでも未来が見える https://www.w3.org/2018/10/TPAC/

Slide 83

Slide 83 text

さらにその未来 (IETF) 引用: https://www.slideshare.net/AmirZ/webrtc-standards-implementation-qa-the-future-is-now2

Slide 84

Slide 84 text

アーキテクチャの再設計へ… ・何年かかるか分からないレベルの話 ・興味あれば次にIETFをWatch 　(IETFは誰でもRemote参加できる) https://tools.ietf.org/html/draft-jennings-dispatch-new-media-01

Slide 85

Slide 85 text

まとめ

Slide 86

Slide 86 text

1. WebRTCの概要 2. 細かいAPIイベントノウハウ 3. WebRTCとNetwork的な話 4. WebRTCの最新動向(未来の話) 本日お話したこと おしまい