実践 WebRTC 〜最新事例と開発ノウハウの紹介〜

5,512 views

Published on

HTML5 Conference 2017 発表資料です。
http://events.html5j.org/conference/2017/9/session/#c1

Published in: Technology
  • Be the first to comment

実践 WebRTC 〜最新事例と開発ノウハウの紹介〜

  1. 1. C 実践 WEBRTC 〜最新事例と開発ノウハウの紹介〜 HTML5 Conference 2017 発表資料 2017 / 09/ 24
  2. 2. 自己紹介 • 仲 裕介 • Twitter:@Tukimikage • NTT Communications エンジニア • WebRTC Platform SkyWay • デベロッパーリレーション担当 • テクニカルソリューション(テクニカルコンサル/サポート)担当 • コミュニティ運営 • WebRTC Meetup Tokyo / Osaka 主催 • WebRTC Beginners Tokyo 主催
  3. 3. 今日のゴール(目的) • WebRTC聞いたことがある…という人が使ってみたい!と思う • WebRTCを支える技術について、少しだけ他人に説明できるようになる • WebRTCを利用した開発の勘所をつかんでもらう • 午後の「詳解WebRTC」でもっと深いところまで聞きたくなる
  4. 4. WebRTCとは? Web Real Time Communication の略 IPネットワークで 同時 / 即時 / 瞬時の 通信 / 意思疎通をする オープン標準技術
  5. 5. www.flickr.com/photos/tjflex/57210112 リアルタイム コミュニケーションの 民主化
  6. 6. www.flickr.com/photos/mattb_tv/2550476978 最初のリアルタイムコミュニケーションは電話 1876年以来、電話会社が独占
  7. 7. 2000年前後、NapsterやSkypeがインターネット上 で実現 www.flickr.com/photos/132889348@N07/18410514419
  8. 8. 2011年にWebRTCの草案が発表され、全てのソフト ウェアエンジニアが扱える時代が到来 www.flickr.com/photos/86979666@N00/6990460438
  9. 9. 従来のWeb サーバ⇔ク ライアント 間の通信 リクエストと レスポンスの 繰り返し サーバ WebRTCで出来ること
  10. 10. 従来のWeb WebRTC カメラやマイ クを利⽤可 ストリーミング データを扱える ブラウザ間 のP2P通信 サーバ⇔ク ライアント 間の通信 リクエストと レスポンスの 繰り返し サーバ サーバ WebRTCで出来ること
  11. 11. WebRTCを構成する技術要素 • WebRTCはオープン標準技術。ライセンス使⽤料が不要。 • 中⾝は4つ。IETF(①~③)とW3C(④)で標準化。 ①暗号化、到達・順序保証、流量・輻輳制御を実現する プロトコル ②ネットワーク機器(NAT等)を越えてP2P通信する⼿順 ③⾳声と映像の形式(コーデック) ④JavaScript等から利⽤するAPI
  12. 12. chimera.labs.oreilly.com/books/1230000000545/ch18.html ①暗号化、到達・順序保証、流量・輻輳制御を実現するプロトコル ②ネットワーク機器(NAT等)を越えてP2P通信する⼿順 ④JavaScript等から利⽤するAPI
  13. 13. chimera.labs.oreilly.com/books/1230000000545/ch18.html ①暗号化、到達・順序保証、流量・輻輳制御を実現するプロトコル ②ネットワーク機器(NAT等)を越えてP2P通信する⼿順 ④JavaScript等から利⽤するAPI
  14. 14. ③⾳声と映像の形式(コーデック)
  15. 15. WebRTCを構成する技術要素 • WebRTCはオープン標準技術。ライセンス使⽤料が不要。 • 中⾝は4つ。IETF(①~③)とW3C(④)で標準化。 ①暗号化、到達・順序保証、流量・輻輳制御を実現する プロトコル ②ネットワーク機器(NAT等)を越えてP2P通信する⼿順 ③⾳声と映像の形式(コーデック) ④JavaScript等から利⽤するAPI WebRTCの内部は結構複雑…
  16. 16. 詳しく知りたい⽅はこちらのセッションに是⾮参加してみてください
  17. 17. WebRTCのブラウザ対応状況 caniuse.com
  18. 18. WebRTCのブラウザ対応状況 caniuse.com いい加減諦めてください…
  19. 19. WebRTCのブラウザ対応状況 caniuse.com はーい、こちらに注目!
  20. 20. 2017/9/20…ついにWebRTCをサポート! iOS11 x Safari11 macOS Sierra+ x Safari11
  21. 21. SafariがWebRTCに対応する意義 •アプリを作る必要がない •導入ハードルがぐっと下がる
  22. 22. lab.syncer.jp 特に⽇本だとモバイルにおけるSafariのシェアは65%以上
  23. 23. WebRTCが普及する土台は整った
  24. 24. WebRTC☓イノベーション
  25. 25. WebRTCの市場規模予測
  26. 26. WebRTCの市場規模予測(2016/11) •2020年にはコラボレーションアプリの通話の90%以上が WebRTC(出展:ガートナー) •2020年の市場規模は44億5000万ドル(出展: MarketsandMarkets)
  27. 27. 44億ドルって?…ちなみにドローンは60.5億ドル規模らしいです。
  28. 28. WebRTCは様々シーンで イノベーションのためのツールとして 活用されています
  29. 29. mixer.com Co-Streaming(共同ストリーミング) 複数⼈が同時に動画配信し多⼈数が視聴する Mixer : MSが買収したゲーム動画配信サービスでWin10からは直接配信も可能
  30. 30. sketch.pixiv.net/items/3937947988965054025 Co-Streaming(共同ストリーミング) 複数⼈が同時に動画配信し多⼈数が視聴する Pixiv Sketch LIVE : 多人数でリアルタイムにお絵かきを楽しめるライブ配信機能
  31. 31. Serverless CDN ピア・ツー・ピアでクライアントからクライアントへデータを配信す るユースケース Peer5 : 今年7⽉に$2.5Mを調達。テレビ並み(数百万)の同時視聴者数を実現するのが 彼らのミッション
  32. 32. www.streamroot.io Serverless CDN x Streaming 従来のサーバ配信に加えてピア・ツー・ピアでの配信も⾏う Stramroot : 先⽇$3.2M調達が報じられた。Dailymotionなどで利⽤されている
  33. 33. eikaiwa.weblio.jp オンライン英会話 従来Skypeでやっていたオンライン英会話がWebRTCへ移⾏ Weblio、レアジョブ、ネイティブキャンプ、ECC等の事業者は既にWebRTCを活⽤中
  34. 34. カスタマサポート Web上で直接お客様とビデオチャットによる接客を実現 Web組み込み型のコンタクトセンタ。 www.softbank.jp/biz/other/videodesk/
  35. 35. clinics.medley.life/ 遠隔診療 先⽣側(PC)と患者側(スマホアプリ)を利⽤したビデオチャットによる診療を実現 CLINICS : 全国550以上の医療機関で利⽤可能
  36. 36. http://www.petoco.jp/ IoT WebRTCスタックが動くデバイスであれば簡単にコミュニケーション機能を追加可能 petoco: NTTドコモ開発のホームコミュニケーションデバイス
  37. 37. http://www.petoco.jp/ マッチングアプリ 声や映像を利⽤したマッチングアプリ KoeTomo:年齢・性別に関わらず、世界中の⼈たちと話すことができる新感覚ボイス サービス
  38. 38. WebRTCの活用しどころ
  39. 39. 既存サービスの置き換えでコスト削減
  40. 40. 既存サービスの置き換えでコスト削減 付加価値向上
  41. 41. 既存サービスの置き換えでコスト削減 付加価値向上
  42. 42. 前半戦終了
  43. 43. WebRTCを利用した開発の勘所
  44. 44. お品書き 1.WebRTC APIの進化は早い 2.ブラウザ同士の互換性に注意 3.マイクカメラの扱いにはハマりどころが多い 4.多人数通話は出来ないの? 5.WebRTCは開発よりも運用開始後が大変 6.プラットフォームサービスは積極的に活用しよう
  45. 45. 1.WebRTC APIの進化は早い
  46. 46. Safariの開発メニューに有るこの項⽬ご存知ですか?
  47. 47. レガシーWebRTCAPIを有効にする • SafariはレガシーなWebRTCAPIを無効化する気満々です • レガシーAPI • RTCPeerConnectionの各種イベントがCallback方式からPromise方式に変更 • MediaStream単位の操作からMediaStreamTrack単位の操作に変更 • Ex pc.addStream() → pc.addTrack()
  48. 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. 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. 50. 最新のWebRTC1.0へ • 各ブラウザはORTCの考え方を一部取り入れた、最新の WebRTC1.0APIへ対応しつつあります。 RTCPeerConnection - RTCTransceiver - RTCRtpSender - RTCRtpReceiver
  51. 51. ORTCのオブジェクト構成 ortc.org/architecture/
  52. 52. 一部を取り入れている RTCTransceiverRTCTransceiver RTCRtpSender RTCRtpReceiver ortc.org/architecture/
  53. 53. なぜORTCが良いの?
  54. 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. 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. 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の候補
  57. 57. SDPの中にはこれらのレイヤ について、ネゴシエーション を行うために必要な情報が全 て記載されている。 例えば、以下のような時 • 最初音声ミュートで会議に 参加していたメンバが途中 から音声のミュートを解除 する レガシーAPIだと・・・ 音声トラックだけ操作したいの に全てのレイヤで再ネゴが発生
  58. 58. なぜORTCが良いの? RTCTransceiverRTCTransceiver RTCRtpSender RTCRtpReceiver 各レイヤに相当するAPIが公開されている ortc.org/architecture/
  59. 59. このレイヤは触らなくていい このレイヤを操作(メディ アトラックの追加や削除) したい ORTCだと・・・
  60. 60. この話がわかりやすく解説されています SDP: Your Fears Are Unleashed https://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/
  61. 61. bokete.jp/odai/2807035
  62. 62. そんなAPIの進化ついていけない… 大丈夫です。 adapter.js(shim)を使えばだいたいうまくやってくれます。 Shim to insulate apps from spec changes and prefix differences https://github.com/webrtc/adapter/
  63. 63. 2.ブラウザの互換性に注意
  64. 64. なぜ差分が生まれるのか?
  65. 65. コアライブラリが異なります Googleが公開しているWebRTCライブラリがベース(一部独自作り込み有り) 完全独自っぽい (非公開)
  66. 66. 参考:各ブラウザのアーキテクチャ https://www.slideshare.net/AmirZ/webrtc-standards-implementation-qa-the-internals-of-webrtc-browsers-implementation
  67. 67. 動画コーデックのサポートが異なります VP8/VP9/H264 H264VP8/H264UC WebRTC的にはスタンダード Skype用にH264UC 恐らくモバイルを 考慮し一択
  68. 68. 搭載されているAPIに差分があります WebRTC 1.0 (MediaChannel/DataChannel) , getUserMedia , ScreenShare ORTC, WebRTC 1.0 (MediaChannel), getUserMedia
  69. 69. 搭載されているAPIに差分があります 機能差分はAdapter.jsでも吸収できないので、アプリの作り込みで吸収する必要あり
  70. 70. 参考:Safariに関する細かいAPI差分 Chrome、Firefoxのノリで使うとつまります • iPod touchはaudioに未対応です。 • Video要素には、属性として"playsinline"を必ず指定してください。 • 動画の再生には “.play()” をご利用ください。“autoplay” 属性を指定するだけでは、動画 が再生されない場合があります。 • 一部の環境ではWebページ上でユーザ操作が無い場合には、動画が再生されないケースが ございます。その場合は、クリック/タップなどのユーザ操作が含まれるようにアプリケー ションを作成ください。 • スクロールやピンチイン・アウト等を契機に、端末がフリーズする場合があります。その場 合は、相手の映像を表示するvideo要素に"position: -webkit-sticky;"を指定すると、改善さ れる場合があります。 2017/9/20現在
  71. 71. 3.マイクカメラの扱いにはハマりどころが多い www.logicool.co.jp/ja-jp/video/webcams OS ブラウザ ビデオキャプ チャエンジン ブラウザ API JS カメラの機種による差分、OSレベルの差分、ブラウザ毎の差分を考慮して、JSで操作する…
  72. 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. 73. くせものです… • getUserMediaのConstraints • {video: true, audio: true} • Constraintsとは制約条件のことで、JS開発者はAPIの引き数に制約条件を与え てカメラ映像やマイク音声を取得する • オプション指定ではなく制約なので100%その通りになるとは限らない… • 書き方に幅がある… • おまけにブラウザごとに実装にムラがある… • 利用者の環境は千差万別、考えて指定しないとカメラが取得できないです…と いう問合せがくる…
  74. 74. 雰囲気じゃなくてちゃんとやりたい人はこれ読もう • https://goo.gl/9DWMGZ @leader22
  75. 75. 4.多人数通話はできないの?
  76. 76. 多人数通話には3つ方法がある • フルメッシュ • MCU • SFU
  77. 77. フルメッシュ • P2Pの応用でクライアント側のみ で実現可能 • 接続台数が増えると送受信先が増 えクライアントの負荷が増える
  78. 78. MCU • MCU(Multipoint Control Unit) で映像・音声をミキシングする • 接続台数が増えても送受信先の数 が変わらないため、クライアント 負荷は増えないが、代わりにサー バの負荷が増える MCU
  79. 79. SFU • SFU(Selective Forwarding Unit)で 映像・音声をコピーし配信 • 送信ストリームは接続台数に関係なく 1本であり、クライアントの負荷を軽 減できる • WebRTCでは主流の形式 • ソフトウェア方式のSFU(有償/無償) • PaaSとして提供しているSFUあり SFU
  80. 80. ユースケースにあわせて選択しましょう
  81. 81. 5.WebRTCは運用開始後が大変…
  82. 82. つながらない問題
  83. 83. シグナリング・メディア通信 WebRTCにはシグナリングとメディア、2つの通信がある Webサーバ Aさん Bさん シグナリングサーバ シグナリング メディアプレーン
  84. 84. 参考:シグナリング 音声・映像等の通信を開始する前に通信相手と以下の情報を共有・交渉する No 主要な情報 必要な理由 1 通信を開始したい旨、応答したい旨 どのタイミングで通信を開始して良いかわからないので 2 通信相⼿のIPアドレス・ポート番号 どこにパケットを送れば良いか分からないので 3 トランスポートプロトコル TCP、UDP※のどちらを使えば良いか分からないため (※特にWebRTCではUDPをRTPでカプセル化している) 4 メディア種別 (⾳声、映像 等) ⾳声のみで通信したいのか、 映像も併⽤したいのか分からないため 5 コーデック (H.264、VP8 等) どんなコーデック(符号化⽅式)で 相⼿と通信するか分からないので 6 暗号化情報(鍵・アルゴリズム 等) どんな暗号化⽅式、共有鍵を⽤いるか分からないので ※先述したSDPの記述⽅法でこれらを交換する
  85. 85. つながらないパターン 1.シグナリングサーバと接続(だいたいWSS)ができない 2.メディアの通信(P2P)が疎通できない Webサーバ Aさん Bさん シグナリングサーバ シグナリング メディアプレーン
  86. 86. つながらないパターン 1.シグナリングサーバとの接続(だいたいWSS)ができない 理由:WebSocket禁止、プロキシサーバ有り(法人ユーザに多い) 解決策1:疎通できるようにネットワークのポリシー変更 解決策2:イントラネット内にシグナリングサーバを立てる
  87. 87. つながらないパターン 2.メディアの通信(P2P)が疎通できない 理由:NATタイプがセキュア、 P2PやUDP通信が禁止されている 解決策1:疎通できるようにネットワークのポリシー変更 解決策2:TURNサーバを用意する
  88. 88. ICE WebRTCではICEというプロコルを用いてP2P通信の経路を確立する その際に利用されるユーティリティがSTUNサーバ、TURNサーバである
  89. 89. 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アドレスとポート番号の両⽅が含まれる
  90. 90. 参考:UDPホールパンチング NAT NAT STUNサーバ
  91. 91. 参考:UDPホールパンチング NAT STUNサーバ NAT NATの外側のIPアドレス ポート番号が知りたい 111.111.111.111 50000番
  92. 92. 参考:UDPホールパンチング NAT STUNサーバ NAT NATの外側のIPアドレス ポート番号が知りたい 222.222.222.222 55000番 IP : 111.111.111.111 Port : 50000
  93. 93. 参考:UDPホールパンチング NAT STUNサーバ NAT IP : 222.222.222.222 Port : 55000 IP : 111.111.111.111 Port : 50000 ICE候補として シグナリングで交換
  94. 94. 参考:UDPホールパンチング NATNAT相⼿のIP・ポートに向かっ てUDPパケットを送信 ⽳が開く (折り返しが受けられる) よくわからない通信は落と される IP : 222.222.222.222 Port : 55000 IP : 111.111.111.111 Port : 50000
  95. 95. 参考:UDPホールパンチング NATNAT 折り返し⽤の⽳を上⼿く通 過する ⽳が開く (折り返しが受けられる) 相⼿のIP・ポートに向かっ てUDPパケットを送信 IP : 222.222.222.222 Port : 55000 IP : 111.111.111.111 Port : 50000 相⼿に届く (以後双⽅向で通信できる)
  96. 96. ICE • UDPホールパンチングできるNATの種類には制限がある NAT Type フルコーン 制限付きフル コーン ポート制限付 きフルコーン シンメトリッ ク フルコーン 可 可 可 可 制限付きフル コーン 可 可 可 可 ポート制限付 きフルコーン 可 可 可 不可 シンメトリッ ク 可 可 不可 不可
  97. 97. 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 クライアント (ブラウザ) 通信するための準備
  98. 98. ICE • TURN • UDPホールパンチングで通信ができない場合にメディアを中継する • FW等でUDPパケットの通信が禁止されている場合にも有効 TURN サーバ Aさん:TURN クライアント (ブラウザ) ①Create Permissionリクエスト (★のアドレスを使ってBさんと 通信したいので許可をください) ③メディアを流すと中継してくれる Bさん:TURN クライアント (ブラウザ) 準備が整ったら許可を求める メディアが中継される
  99. 99. 参考:TURN通信パターン • WebRTCにおけるTURN通信は2パターンある(その1) 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
  100. 100. 参考:TURN通信パターン • WebRTCにおけるTURN通信は2パターンある(その2) 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通信
  101. 101. つながらない問題を切り分ける
  102. 102. デバッグ方法 ブラウザデバッグツールを活用する • Chromeがおすすめ • chrome://webrtc-internals
  103. 103. デバッグ方法 ネットワーク関連の情報(よく使う項目) 項目 意味 timestamp タイムスタンプ 現在利用しているTransportかどうかはこのタイム スタンプが更新されているかどうかで判断 googxxxxAddress ローカル・リモートそれぞれのIPアドレスとポー ト番号 xxxxCandidateId ローカル・リモートそれぞれで採択された Candidate情報のID※1(通信するためのIPアドレス、 ポート番号等の候補情報) このIDでサイト内を検索すると詳細が確認できる googxxxxCandidateType ローカル・リモートそれぞれのCandidateタイプ relay : TURN経由の接続 それ以外 : TURNを使用せずにダイレクト接続
  104. 104. デバッグ方法 メディア関連の情報 項目 意味 msid MediaStreamIDでAudioTrackとVideoTrack を束ねた1つのStreamを指す JavaScriptから識別することができる timestamp タイムスタンプ 有効なTrackかどうかはこのタイムスタンプが 更新されているかどうかで判断 bytesSent 送受信バイト数 mediaType audio/video packetsLost パケットがロストした場合に表示される ssrc Synchronisation Sourceという。ここでは RTP(リアルタイムプロトコル)で利用する識 別子 transportId 先程見た Conn-xxxx-x-x に該当 このTrackがどのTransport(輸送路)を利用 しているかわかる googCodecName 使用しているコーデック googTrackId TrackIDでJavaScriptから識別することもがで きる
  105. 105. デバッグ方法 メディア関連の情報 320x240/10fps 640x480/30fps 1920x1080/30fps
  106. 106. これらの情報を参考に原因究明と解決策 を見出す
  107. 107. 6. プラットフォームサービスは積極的 に活用しよう
  108. 108. WebRTCは総合格闘技
  109. 109. WebRTCは導入は簡単です。 でも、本格的に使う場合、全て自分でや るのは地獄を見るかもしれません…
  110. 110. 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
  111. 111. プラットフォームサービスを活用する場合 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. 112. プラットフォームサービス OpenTok tokbox SFUを利用した多対多配信が特徴 CafeX Cafex Communications LiveAssist等のWebRTC対応コンタクトセ ンターソリューションを提供
  113. 113. プラットフォームサービス SkyWay NTT Communications ⽇本企業で唯⼀のプラットフォームサー ビス、トライアル中は無料 Twillio twillio SIPとWebRTCを中継するSBC機能が特徴
  114. 114. プラットフォームサービス FacePeer FacePeer BtoBtoC向けのビデオチャットプラ フォームを提供
  115. 115. ミドルウェア WebRTC SFU Sora 時⾬堂 国産ソフトウェアベースのSFUを提供
  116. 116. 是非有効活用してみてください
  117. 117. 注意 プラットフォームサービスを利用しても、 つながらない問題とかが全て解決するわ けではありません
  118. 118. WebRTCを利用した開発の勘所、つか んでもらえましたか?
  119. 119. 最後にちょっと宣伝させてください
  120. 120. SkyWayは個人やスタートアップ向けに 無料枠が有ります。 とりあえず使ってみてください。
  121. 121. SkyWay Developer Meetup #1 ■日時 : 2017年9月29日(金)18:30開場 19:00開始 ■会場 : いいオフィス 東京都台東区東上野2-18-7共同ビル3F ■定員 : 200名 ■参加費: 無料/登録制 事前登録はこちら ※詳しくはイベントサイトをご覧ください。 https://skyway.connpass.com/event/65697/
  122. 122. ご清聴ありがとうございました!

×