実践 WebRTC ?最新事例と開発ノウハウの紹介?
21 likes17,477 views
HTML5 Conference 2017 発表資料です。 http://events.html5j.org/conference/2017/9/session/#c1
![pc.addTrack
// get a local stream, show it in a self-view and add it to be sent
navigator.mediaDevices.getUserMedia({ "audio": true, "video": true },
function (stream) {
selfView.srcObject = stream;
if (stream.getAudioTracks().length > 0)
pc.addTrack(stream.getAudioTracks()[0], stream);
if (stream.getVideoTracks().length > 0)
pc.addTrack(stream.getVideoTracks()[0], stream);
}, logError);](https://image.slidesharecdn.com/html5conf20170924-170923221538/85/WebRTC-49-320.jpg)
More Related Content
What's hot (20)
Similar to 実践 WebRTC ?最新事例と開発ノウハウの紹介? (20)
More from Yusuke Naka (20)
Recently uploaded (6)
実践 WebRTC ?最新事例と開発ノウハウの紹介?
- 1. C 実践 WEBRTC ?最新事例と開発ノウハウの紹介? HTML5 Conference 2017 発表資料 2017 / 09/ 24
- 2. 自己紹介 ? 仲 裕介 ? Twitter：@Tukimikage ? NTT Communications エンジニア ? WebRTC Platform SkyWay ? デベロッパーリレーション担当 ? テクニカルソリューション(テクニカルコンサル／サポート)担当 ? コミュニティ運営 ? WebRTC Meetup Tokyo / Osaka 主催 ? WebRTC Beginners Tokyo 主催
- 3. 今日のゴール（目的） ? WebRTC聞いたことがある…という人が使ってみたい！と思う ? WebRTCを支える技術について、少しだけ他人に説明できるようになる ? 奥别产搁罢颁を利用した开発の勘所をつかんでもらう ? 午後の「詳解WebRTC」でもっと深いところまで聞きたくなる
- 4. WebRTCとは？ Web Real Time Communication の略 IPネットワークで 同時 / 即時 / 瞬時の 通信 / 意思疎通をする オープン標準技術
- 14. ③?声と映像の形式(コーデック)
- 20. 2017/9/20…ついにWebRTCをサポート！ iOS11 x Safari11 macOS Sierra+ x Safari11
- 24. 奥别产搁罢颁?イノベーション
- 25. 奥别产搁罢颁の市场规模予测
- 29. mixer.com Co-Streaming（共同ストリーミング） 複数?が同時に動画配信し多?数が視聴する Mixer : MSが買収したゲーム動画配信サービスでWin10からは直接配信も可能
- 30. sketch.pixiv.net/items/3937947988965054025 Co-Streaming（共同ストリーミング） 複数?が同時に動画配信し多?数が視聴する Pixiv Sketch LIVE : 多人数でリアルタイムにお絵かきを楽しめるライブ配信機能
- 31. Serverless CDN ピア?ツー?ピアでクライアントからクライアントへデータを配信す るユースケース Peer5 : 今年7?に$2.5Mを調達。テレビ並み（数百万）の同時視聴者数を実現するのが 彼らのミッション
- 32. www.streamroot.io Serverless CDN x Streaming 従来のサーバ配信に加えてピア?ツー?ピアでの配信も?う Stramroot : 先?$3.2M調達が報じられた。Dailymotionなどで利?されている
- 36. http://www.petoco.jp/ IoT WebRTCスタックが動くデバイスであれば簡単にコミュニケーション機能を追加可能 petoco: NTTドコモ開発のホームコミュニケーションデバイス
- 38. 奥别产搁罢颁の活用しどころ
- 42. 前半戦终了
- 43. 奥别产搁罢颁を利用した开発の勘所
- 47. レガシーWebRTCAPIを有効にする ? SafariはレガシーなWebRTCAPIを無効化する気満々です ? レガシーAPI ? RTCPeerConnectionの各種イベントがCallback方式からPromise方式に変更 ? MediaStream単位の操作からMediaStreamTrack単位の操作に変更 ? Ex pc.addStream() → pc.addTrack()
- 48. PromiseベースのAPI // let the "negotiationneeded" event trigger offer generation pc.onnegotiationneeded = function () { pc.createOffer().then(function (offer) { return pc.setLocalDescription(offer); }) .then(function () { // send the offer to the other peer signalingChannel.send(JSON.stringify({ "desc": pc.localDescription })); }) .catch(logError); };
- 49. pc.addTrack // get a local stream, show it in a self-view and add it to be sent navigator.mediaDevices.getUserMedia({ "audio": true, "video": true }, function (stream) { selfView.srcObject = stream; if (stream.getAudioTracks().length > 0) pc.addTrack(stream.getAudioTracks()[0], stream); if (stream.getVideoTracks().length > 0) pc.addTrack(stream.getVideoTracks()[0], stream); }, logError);
- 50. 最新のWebRTC1.0へ ? 各ブラウザはORTCの考え方を一部取り入れた、最新の WebRTC1.0APIへ対応しつつあります。 RTCPeerConnection - RTCTransceiver - RTCRtpSender - RTCRtpReceiver
- 53. なぜ翱搁罢颁が良いの？
- 54. WebRTC1.0ではSDPを利用する WebRTCのセッションを張る際に必要な情報の交換（シグナリング）に、 SDPというフォーマットを利用する v=0 (…中略…) a=group:BUNDLE audio video m=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126 (…中略…) c=IN IP4 100.1.2.3 a=rtcp:54321 IN IP4 100.1.2.3 a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0 a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0 (…中略…) a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 (…以下略…) トランスポートプロトコ ルにSRTPを利??声を利? ポート番号は 54321
- 55. WebRTC1.0ではSDPを利用する v=0 (…中略…) a=group:BUNDLE audio video m=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126 (…中略…) c=IN IP4 100.1.2.3 a=rtcp:54321 IN IP4 100.1.2.3 a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0 a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0 (…中略…) a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 (…以下略…) コーデック番号(下部とリンク) Opus(48000kHzでステレオ)を利?したい 必要な情報をSDPというフォーマットで相手に伝える
- 56. WebRTC1.0ではSDPを利用する 必要な情報をSDPというフォーマットで相手に伝える v=0 (…中略…) a=group:BUNDLE audio video m=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126 (…中略…) c=IN IP4 100.1.2.3 a=rtcp:54321 IN IP4 100.1.2.3 a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0 a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0 (…中略…) a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 (…以下略…) ICEの候補
- 60. この話がわかりやすく解説されています SDP: Your Fears Are Unleashed https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/
- 62. そんなAPIの進化ついていけない… 大丈夫です。 adapter.js（shim）を使えばだいたいうまくやってくれます。 Shim to insulate apps from spec changes and prefix differences https://github.com/webrtc/adapter/
- 63. 2．ブラウザの互换性に注意
- 64. なぜ差分が生まれるのか？
- 68. 搭載されているAPIに差分があります WebRTC 1.0 (MediaChannel/DataChannel) , getUserMedia , ScreenShare ORTC, WebRTC 1.0 (MediaChannel), getUserMedia
- 70. 参考：Safariに関する細かいAPI差分 Chrome、Firefoxのノリで使うとつまります ? iPod touchはaudioに未対応です。 ? Video要素には、属性として"playsinline"を必ず指定してください。 ? 動画の再生には “.play()” をご利用ください。“autoplay” 属性を指定するだけでは、動画 が再生されない場合があります。 ? 一部の環境ではWebページ上でユーザ操作が無い場合には、動画が再生されないケースが ございます。その場合は、クリック/タップなどのユーザ操作が含まれるようにアプリケー ションを作成ください。 ? スクロールやピンチイン?アウト等を契機に、端末がフリーズする場合があります。その場 合は、相手の映像を表示するvideo要素に"position: -webkit-sticky;"を指定すると、改善さ れる場合があります。 2017/9/20現在
- 72. getUserMediaという便利APIはあるけれど // getUserMediaでカメラ、マイクにアクセス function startVideo() { navigator.mediaDevices.getUserMedia({video: true, audio: true}) .then(function (stream) { // success playVideo(localVideo,stream); localStream = stream; }) .catch(function (error) { // error console.error('mediaDevice.getUserMedia() error:', error); return; }); } // Videoの再生を開始する function playVideo(element, stream) { element.srcObject = stream; element.play(); }
- 73. くせものです… ? getUserMediaのConstraints ? {video: true, audio: true} ? Constraintsとは制約条件のことで、JS開発者はAPIの引き数に制約条件を与え てカメラ映像やマイク音声を取得する ? オプション指定ではなく制約なので100％その通りになるとは限らない… ? 書き方に幅がある… ? おまけにブラウザごとに実装にムラがある… ? 利用者の環境は千差万別、考えて指定しないとカメラが取得できないです…と いう問合せがくる…
- 76. 4．多人数通话はできないの？
- 77. 多人数通話には3つ方法がある ? フルメッシュ ? MCU ? SFU
- 79. MCU ? MCU（Multipoint Control Unit） で映像?音声をミキシングする ? 接続台数が増えても送受信先の数 が変わらないため、クライアント 負荷は増えないが、代わりにサー バの負荷が増える MCU
- 80. SFU ? SFU（Selective Forwarding Unit）で 映像?音声をコピーし配信 ? 送信ストリームは接続台数に関係なく １本であり、クライアントの負荷を軽 減できる ? WebRTCでは主流の形式 ? ソフトウェア方式のSFU（有償/無償） ? PaaSとして提供しているSFUあり SFU
- 83. つながらない问题
- 85. 参考：シグナリング 音声?映像等の通信を開始する前に通信相手と以下の情報を共有?交渉する No 主要な情報 必要な理由 1 通信を開始したい旨、応答したい旨 どのタイミングで通信を開始して良いかわからないので 2 通信相?のIPアドレス?ポート番号 どこにパケットを送れば良いか分からないので 3 トランスポートプロトコル TCP、UDP※のどちらを使えば良いか分からないため （※特にWebRTCではUDPをRTPでカプセル化している） 4 メディア種別 （?声、映像 等） ?声のみで通信したいのか、 映像も併?したいのか分からないため 5 コーデック （H.264、VP8 等） どんなコーデック（符号化?式）で 相?と通信するか分からないので 6 暗号化情報（鍵?アルゴリズム 等） どんな暗号化?式、共有鍵を?いるか分からないので ※先述したSDPの記述?法でこれらを交換する
- 90. ICE ? STUN ? NATを越えるためのユーティリティ ? 自分のグローバルIPアドレス、ポート番号を知ることが出来る ? 得られた情報を利用してUDPホールパンチングを実施する STUN サーバSTUN クライアント (ブラウザ) NAT Binding Request 送信元IP：STUNクライアント 送信先IP：STUNサーバ Binding Request 送信元IP：NATの外側のIP(★) 送信先IP：STUNサーバ Binding Response 送信元IP：STUNサーバ 送信先IP：NATの外側のIP(★) 本?：NATの外側のIP(★) Binding Response 送信元IP：STUNサーバ 送信先IP：STUNクライアント 本?：NATの外側のIP(★) 補?：上記フローには、実際には IPアドレスとポート番号の両?が含まれる
- 93. 参考：UDPホールパンチング NAT STUNサーバ NAT NATの外側のIPアドレス ポート番号が知りたい 222.222.222.222 55000番 IP : 111.111.111.111 Port : 50000
- 94. 参考：UDPホールパンチング NAT STUNサーバ NAT IP : 222.222.222.222 Port : 55000 IP : 111.111.111.111 Port : 50000 ICE候補として シグナリングで交換
- 95. 参考：UDPホールパンチング NATNAT相?のIP?ポートに向かっ てUDPパケットを送信 ?が開く （折り返しが受けられる） よくわからない通信は落と される IP : 222.222.222.222 Port : 55000 IP : 111.111.111.111 Port : 50000
- 96. 参考：UDPホールパンチング NATNAT 折り返し?の?を上?く通 過する ?が開く （折り返しが受けられる） 相?のIP?ポートに向かっ てUDPパケットを送信 IP : 222.222.222.222 Port : 55000 IP : 111.111.111.111 Port : 50000 相?に届く （以後双?向で通信できる）
- 97. ICE ? UDPホールパンチングできるNATの種類には制限がある NAT Type フルコーン 制限付きフル コーン ポート制限付 きフルコーン シンメトリッ ク フルコーン 可 可 可 可 制限付きフル コーン 可 可 可 可 ポート制限付 きフルコーン 可 可 可 不可 シンメトリッ ク 可 可 不可 不可
- 98. ICE ? TURN ? UDPホールパンチングで通信ができない場合にメディアを中継する ? FW等でUDPパケットの通信が禁止されている場合にも有効 TURN サーバ Aさん：TURN クライアント (ブラウザ) Allocation Request 送信元IP＆ポート：STUNクライアント 送信先IP＆ポート：TURNサーバ Allocation Success Response 送信元IP＆ポート：STUNサーバ 送信先IP＆ポート：TURNクライアント 本?：TURNサーバにて中継?に 払い出すIPアドレスとポート（★） Bさん：TURN クライアント (ブラウザ) 通信するための準備
- 99. ICE ? TURN ? UDPホールパンチングで通信ができない場合にメディアを中継する ? FW等でUDPパケットの通信が禁止されている場合にも有効 TURN サーバ Aさん：TURN クライアント (ブラウザ) ①Create Permissionリクエスト （★のアドレスを使ってBさんと 通信したいので許可をください） ③メディアを流すと中継してくれる Bさん：TURN クライアント (ブラウザ) 準備が整ったら許可を求める メディアが中継される
- 100. 参考：TURN通信パターン ? WebRTCにおけるTURN通信は2パターンある（その１） TURNサーバ Aさん：TURN クライアント Bさん：TURN クライアント TCP通信 Listening Address IP : 111.111.111.111 Port : TCP 3478 UDP通信 Relay Address IP : 111.111.111.111 Port : UDP50000
- 101. 参考：TURN通信パターン ? WebRTCにおけるTURN通信は２パターンある（その２） TURNサーバ （複数台のサーバをリレーする場合もある） Aさん：TURN クライアント Bさん：TURN クライアント Listening Address IP : 111.111.111.111 Port : TCP 3478 Listening Address IP : 111.111.111.111 Port : TCP 3478Relay Address IP : 111.111.111.111 Port : UDP 50000 TCP通信 TCP通信 UDP通信 UDP通信 Relay Address IP : 111.111.111.111 Port : UDP 55000 UDP通信
- 102. つながらない问题を切り分ける
- 104. デバッグ方法 ネットワーク関連の情報（よく使う項目） 項目 意味 timestamp タイムスタンプ 現在利用しているTransportかどうかはこのタイム スタンプが更新されているかどうかで判断 googxxxxAddress ローカル?リモートそれぞれのIPアドレスとポー ト番号 xxxxCandidateId ローカル?リモートそれぞれで採択された Candidate情報のID※1（通信するためのIPアドレス、 ポート番号等の候補情報） このIDでサイト内を検索すると詳細が確認できる googxxxxCandidateType ローカル?リモートそれぞれのCandidateタイプ relay : TURN経由の接続 それ以外 : TURNを使用せずにダイレクト接続
- 105. デバッグ方法 メディア関連の情報 項目 意味 msid MediaStreamIDでAudioTrackとVideoTrack を束ねた１つのStreamを指す JavaScriptから識別することができる timestamp タイムスタンプ 有効なTrackかどうかはこのタイムスタンプが 更新されているかどうかで判断 bytesSent 送受信バイト数 mediaType audio/video packetsLost パケットがロストした場合に表示される ssrc Synchronisation Sourceという。ここでは RTP（リアルタイムプロトコル）で利用する識 別子 transportId 先程見た Conn-xxxx-x-x に該当 このTrackがどのTransport（輸送路）を利用 しているかわかる googCodecName 使用しているコーデック googTrackId TrackIDでJavaScriptから識別することもがで きる
- 109. 奥别产搁罢颁は総合格闘技
- 111. WebRTCを自分で全て開発する場合 WebアプリiOS アプリ アプリ Android アプリ クラウド iOS Android Windows Mac ブラウザ iOS SDK Android SDK JavaScript SDK クラウド Signaling API STUN API TURN API HTML5 API群 WebRTC プロトコル?スタック 自分で開発?用意 第三者が提供 デバイス側 クラウド側 通信 SFU API
- 112. プラットフォームサービスを活用する場合 WebアプリiOS アプリ アプリ Android アプリ クラウド iOS Android Windows Mac ブラウザ iOS SDK Android SDK JavaScript SDK クラウド Signaling API STUN API TURN API HTML5 API群 WebRTC プロトコル?スタック 自分で開発?用意 第三者が提供 デバイス側 クラウド側 通信 プラフォーム事業者が提供 SFU API
- 117. 是非有効活用してみてください
- 120. 最后にちょっと宣伝させてください
- 122. SkyWay Developer Meetup #1 ■日時 ： 2017年9月29日（金）18:30開場 19:00開始 ■会場 ： いいオフィス 東京都台東区東上野2-18-7共同ビル3F ■定員 ： 200名 ■参加費： 無料/登録制 事前登録はこちら ※詳しくはイベントサイトをご覧ください。 https://skyway.connpass.com/event/65697/
- 123. ご清聴ありがとうございました！