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

HTML5 Conference 2017 発表資料2017 / 09/ 24

自己紹介

•仲 裕介

• Twitter：@Tukimikage• NTT Communications エンジニア

• WebRTC Platform SkyWay• デベロッパーリレーション担当

• テクニカルソリューション(テクニカルコンサル／サポート)担当

•コミュニティ運営

• WebRTC Meetup Tokyo / Osaka 主催

• WebRTC Beginners Tokyo 主催

今日のゴール（目的）

•WebRTC聞いたことがある…という人が使ってみたい！と思う

•WebRTCを支える技術について、少しだけ他人に説明できるようになる

•WebRTCを利用した開発の勘所をつかんでもらう

•午後の「詳解WebRTC」でもっと深いところまで聞きたくなる

WebRTCとは？

Web

Real Time

Communication

の略

IPネットワークで

同時 / 即時 / 瞬時の

通信 / 意思疎通をする

オープン標準技術

www.flickr.com/photos/tjflex/57210112

リアルタイムコミュニケーションの

民主化

www.flickr.com/photos/mattb_tv/2550476978

最初のリアルタイムコミュニケーションは電話1876年以来、電話会社が独占

2000年前後、NapsterやSkypeがインターネット上で実現

www.flickr.com/photos/132889348@N07/18410514419

2011年にWebRTCの草案が発表され、全てのソフトウェアエンジニアが扱える時代が到来

www.flickr.com/photos/86979666@N00/6990460438

従来のWeb

サーバ⇔クライアント間の通信

リクエストとレスポンスの繰り返し

サーバ

WebRTCで出来ること

従来のWeb WebRTC

カメラやマイクを利⽤可

ストリーミングデータを扱える

ブラウザ間のP2P通信

サーバ⇔クライアント間の通信

リクエストとレスポンスの繰り返し

サーバ サーバ

WebRTCで出来ること

WebRTCを構成する技術要素

• WebRTCはオープン標準技術。ライセンス使⽤料が不要。• 中⾝は4つ。IETF(①~③)とW3C(④)で標準化。①暗号化、到達・順序保証、流量・輻輳制御を実現するプロトコル②ネットワーク機器(NAT等)を越えてP2P通信する⼿順③⾳声と映像の形式(コーデック) ④JavaScript等から利⽤するAPI

chimera.labs.oreilly.com/books/1230000000545/ch18.html

①暗号化、到達・順序保証、流量・輻輳制御を実現するプロトコル②ネットワーク機器(NAT等)を越えてP2P通信する⼿順④JavaScript等から利⽤するAPI

chimera.labs.oreilly.com/books/1230000000545/ch18.html

①暗号化、到達・順序保証、流量・輻輳制御を実現するプロトコル②ネットワーク機器(NAT等)を越えてP2P通信する⼿順④JavaScript等から利⽤するAPI

③⾳声と映像の形式(コーデック)

WebRTCを構成する技術要素

• WebRTCはオープン標準技術。ライセンス使⽤料が不要。• 中⾝は4つ。IETF(①~③)とW3C(④)で標準化。①暗号化、到達・順序保証、流量・輻輳制御を実現するプロトコル②ネットワーク機器(NAT等)を越えてP2P通信する⼿順③⾳声と映像の形式(コーデック) ④JavaScript等から利⽤するAPI

WebRTCの内部は結構複雑…

詳しく知りたい⽅はこちらのセッションに是⾮参加してみてください

WebRTCのブラウザ対応状況

caniuse.com

WebRTCのブラウザ対応状況

caniuse.com

いい加減諦めてください…

WebRTCのブラウザ対応状況

caniuse.com

はーい、こちらに注目！

2017/9/20…ついにWebRTCをサポート！iOS11 x Safari11macOS Sierra+ x Safari11

SafariがWebRTCに対応する意義

•アプリを作る必要がない

•導入ハードルがぐっと下がる

lab.syncer.jp特に⽇本だとモバイルにおけるSafariのシェアは65%以上

WebRTCが普及する土台は整った

WebRTC☓イノベーション

WebRTCの市場規模予測

WebRTCの市場規模予測(2016/11)

•2020年にはコラボレーションアプリの通話の90%以上がWebRTC（出展：ガートナー）

•2020年の市場規模は44億5000万ドル（出展：MarketsandMarkets）

japan.techrepublic.com/article/35096513.htm

44億ドルって？…ちなみにドローンは60.5億ドル規模らしいです。

WebRTCは様々シーンでイノベーションのためのツールとして

活用されています

mixer.com

Co-Streaming（共同ストリーミング）複数⼈が同時に動画配信し多⼈数が視聴する

Mixer : MSが買収したゲーム動画配信サービスでWin10からは直接配信も可能

sketch.pixiv.net/items/3937947988965054025

Co-Streaming（共同ストリーミング）複数⼈が同時に動画配信し多⼈数が視聴する

Pixiv Sketch LIVE : 多人数でリアルタイムにお絵かきを楽しめるライブ配信機能

Serverless CDNピア・ツー・ピアでクライアントからクライアントへデータを配信するユースケース

Peer5 : 今年7⽉に$2.5Mを調達。テレビ並み（数百万）の同時視聴者数を実現するのが

彼らのミッション

www.streamroot.io

Serverless CDN x Streaming従来のサーバ配信に加えてピア・ツー・ピアでの配信も⾏う

Stramroot : 先⽇$3.2M調達が報じられた。Dailymotionなどで利⽤されている

eikaiwa.weblio.jp

オンライン英会話従来Skypeでやっていたオンライン英会話がWebRTCへ移⾏

Weblio、レアジョブ、ネイティブキャンプ、ECC等の事業者は既にWebRTCを活⽤中

カスタマサポートWeb上で直接お客様とビデオチャットによる接客を実現

Web組み込み型のコンタクトセンタ。www.softbank.jp/biz/other/videodesk/

clinics.medley.life/

遠隔診療先⽣側（PC）と患者側（スマホアプリ）を利⽤したビデオチャットによる診療を実現

CLINICS : 全国550以上の医療機関で利⽤可能

http://www.petoco.jp/

IoTWebRTCスタックが動くデバイスであれば簡単にコミュニケーション機能を追加可能

petoco: NTTドコモ開発のホームコミュニケーションデバイス

http://www.petoco.jp/

マッチングアプリ声や映像を利⽤したマッチングアプリ

KoeTomo:年齢・性別に関わらず、世界中の⼈たちと話すことができる新感覚ボイスサービス

WebRTCの活用しどころ

既存サービスの置き換えでコスト削減

既存サービスの置き換えでコスト削減

付加価値向上

既存サービスの置き換えでコスト削減

付加価値向上

前半戦終了

WebRTCを利用した開発の勘所

お品書き

1.WebRTC APIの進化は早い2.ブラウザ同士の互換性に注意3.マイクカメラの扱いにはハマりどころが多い4.多人数通話は出来ないの？5.WebRTCは開発よりも運用開始後が大変6.プラットフォームサービスは積極的に活用しよう

１．WebRTC APIの進化は早い

Safariの開発メニューに有るこの項⽬ご存知ですか？

レガシーWebRTCAPIを有効にする

• SafariはレガシーなWebRTCAPIを無効化する気満々です

•レガシーAPI• RTCPeerConnectionの各種イベントがCallback方式からPromise方式に変更

• MediaStream単位の操作からMediaStreamTrack単位の操作に変更

• Ex pc.addStream() → pc.addTrack()

PromiseベースのAPI// let the "negotiationneeded" event trigger offer generationpc.onnegotiationneeded = function () {

pc.createOffer().then(function (offer) {return pc.setLocalDescription(offer);

}).then(function () {

// send the offer to the other peersignalingChannel.send(JSON.stringify({ "desc":pc.localDescription }));

}).catch(logError);

};

pc.addTrack// get a local stream, show it in a self-view and add it to be sentnavigator.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);

最新のWebRTC1.0へ•各ブラウザはORTCの考え方を一部取り入れた、最新の

WebRTC1.0APIへ対応しつつあります。

RTCPeerConnection

- RTCTransceiver

- RTCRtpSender

- RTCRtpReceiver

ORTCのオブジェクト構成

ortc.org/architecture/

一部を取り入れている

RTCTransceiverRTCTransceiverRTCRtpSender

RTCRtpReceiver

ortc.org/architecture/

なぜORTCが良いの？

WebRTC1.0ではSDPを利用するWebRTCのセッションを張る際に必要な情報の交換（シグナリング）に、SDPというフォーマットを利用する

v=0(…中略…)a=group:BUNDLE audio videom=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126(…中略…)c=IN IP4 100.1.2.3a=rtcp:54321 IN IP4 100.1.2.3a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0(…中略…)a=rtpmap:111 opus/48000/2a=fmtp:111 minptime=10a=rtpmap:103 ISAC/16000a=rtpmap:104 ISAC/32000a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000(…以下略…)

トランスポートプロトコルにSRTPを利⽤⾳声を利⽤

ポート番号は54321

WebRTC1.0ではSDPを利用する

v=0(…中略…)a=group:BUNDLE audio videom=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126(…中略…)c=IN IP4 100.1.2.3a=rtcp:54321 IN IP4 100.1.2.3a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0(…中略…)a=rtpmap:111 opus/48000/2a=fmtp:111 minptime=10a=rtpmap:103 ISAC/16000a=rtpmap:104 ISAC/32000a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000(…以下略…)

コーデック番号(下部とリンク)

Opus(48000kHzでステレオ)を利⽤したい

必要な情報をSDPというフォーマットで相手に伝える

WebRTC1.0ではSDPを利用する必要な情報をSDPというフォーマットで相手に伝える

v=0(…中略…)a=group:BUNDLE audio videom=audio 54321 RTP/SAVPF 111 103 104 0 8 106 105 13 126(…中略…)c=IN IP4 100.1.2.3a=rtcp:54321 IN IP4 100.1.2.3a=candidate:4022866446 1 udp 2113937151 192.168.0.1 34567 typ host generation 0a=candidate:4022866446 2 udp 2113937151 192.168.0.1 34567 typ host generation 0(…中略…)a=rtpmap:111 opus/48000/2a=fmtp:111 minptime=10a=rtpmap:103 ISAC/16000a=rtpmap:104 ISAC/32000a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000(…以下略…)

ICEの候補

SDPの中にはこれらのレイヤ

について、ネゴシエーションを行うために必要な情報が全て記載されている。

例えば、以下のような時

• 最初音声ミュートで会議に参加していたメンバが途中から音声のミュートを解除する

レガシーAPIだと・・・

音声トラックだけ操作したいのに全てのレイヤで再ネゴが発生

なぜORTCが良いの？

RTCTransceiverRTCTransceiverRTCRtpSender

RTCRtpReceiver

各レイヤに相当するAPIが公開されているortc.org/architecture/

このレイヤは触らなくていい

このレイヤを操作（メディアトラックの追加や削除）したい

ORTCだと・・・

この話がわかりやすく解説されています

SDP: Your Fears Are Unleashedhttps://webrtchacks.com/webrtc-sdp-inaki-baz-castillo/

bokete.jp/odai/2807035

そんなAPIの進化ついていけない…大丈夫です。adapter.js（shim）を使えばだいたいうまくやってくれます。

Shim to insulate apps from spec changes and prefix differenceshttps://github.com/webrtc/adapter/

2．ブラウザの互換性に注意

なぜ差分が生まれるのか？

コアライブラリが異なります

Googleが公開しているWebRTCライブラリがベース（一部独自作り込み有り） 完全独自っぽい（非公開）

参考：各ブラウザのアーキテクチャ

https://www.slideshare.net/AmirZ/webrtc-standards-implementation-qa-the-internals-of-webrtc-browsers-implementation

動画コーデックのサポートが異なります

VP8/VP9/H264 H264VP8/H264UCWebRTC的にはスタンダード Skype用にH264UC 恐らくモバイルを

考慮し一択

搭載されているAPIに差分があります

WebRTC 1.0 (MediaChannel/DataChannel) , getUserMedia , ScreenShare ORTC,WebRTC 1.0(MediaChannel),getUserMedia

搭載されているAPIに差分があります

機能差分はAdapter.jsでも吸収できないので、アプリの作り込みで吸収する必要あり

参考：Safariに関する細かいAPI差分

Chrome、Firefoxのノリで使うとつまります

• iPod touchはaudioに未対応です。• Video要素には、属性として"playsinline"を必ず指定してください。• 動画の再生には “.play()” をご利用ください。“autoplay” 属性を指定するだけでは、動画

が再生されない場合があります。• 一部の環境ではWebページ上でユーザ操作が無い場合には、動画が再生されないケースが

ございます。その場合は、クリック/タップなどのユーザ操作が含まれるようにアプリケーションを作成ください。

• スクロールやピンチイン・アウト等を契機に、端末がフリーズする場合があります。その場合は、相手の映像を表示するvideo要素に"position: -webkit-sticky;"を指定すると、改善される場合があります。

2017/9/20現在

3．マイクカメラの扱いにはハマりどころが多い

www.logicool.co.jp/ja-jp/video/webcams

OSブラウザ

ビデオキャプチャエンジン

ブラウザAPI JS

カメラの機種による差分、OSレベルの差分、ブラウザ毎の差分を考慮して、JSで操作する…

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();}

くせものです…• getUserMediaのConstraints• {video: true, audio: true}

• Constraintsとは制約条件のことで、JS開発者はAPIの引き数に制約条件を与えてカメラ映像やマイク音声を取得する

• オプション指定ではなく制約なので100％その通りになるとは限らない…• 書き方に幅がある…• おまけにブラウザごとに実装にムラがある…• 利用者の環境は千差万別、考えて指定しないとカメラが取得できないです…という問合せがくる…

雰囲気じゃなくてちゃんとやりたい人はこれ読もう

• https://goo.gl/9DWMGZ

@leader22

4．多人数通話はできないの？

多人数通話には3つ方法がある

•フルメッシュ

•MCU

• SFU

フルメッシュ

• P2Pの応用でクライアント側のみで実現可能

•接続台数が増えると送受信先が増えクライアントの負荷が増える

MCU•MCU（Multipoint Control Unit）で映像・音声をミキシングする

•接続台数が増えても送受信先の数が変わらないため、クライアント負荷は増えないが、代わりにサーバの負荷が増える MCU

SFU• SFU（Selective Forwarding Unit）で映像・音声をコピーし配信

•送信ストリームは接続台数に関係なく１本であり、クライアントの負荷を軽減できる

•WebRTCでは主流の形式

•ソフトウェア方式のSFU（有償/無償）

• PaaSとして提供しているSFUあり

SFU

ユースケースにあわせて選択しましょう

5．WebRTCは運用開始後が大変…

つながらない問題

シグナリング・メディア通信WebRTCにはシグナリングとメディア、2つの通信がある

Webサーバ

Aさん Bさん

シグナリングサーバ

シグナリング

メディアプレーン

参考：シグナリング音声・映像等の通信を開始する前に通信相手と以下の情報を共有・交渉する

No 主要な情報 必要な理由

1 通信を開始したい旨、応答したい旨 どのタイミングで通信を開始して良いかわからないので

2 通信相⼿のIPアドレス・ポート番号 どこにパケットを送れば良いか分からないので

3 トランスポートプロトコル TCP、UDP※のどちらを使えば良いか分からないため（※特にWebRTCではUDPをRTPでカプセル化している）

4 メディア種別（⾳声、映像 等）

⾳声のみで通信したいのか、映像も併⽤したいのか分からないため

5 コーデック（H.264、VP8 等）

どんなコーデック（符号化⽅式）で相⼿と通信するか分からないので

6 暗号化情報（鍵・アルゴリズム 等） どんな暗号化⽅式、共有鍵を⽤いるか分からないので

※先述したSDPの記述⽅法でこれらを交換する

つながらないパターン１．シグナリングサーバと接続（だいたいWSS）ができない

２．メディアの通信（P2P）が疎通できない

Webサーバ

Aさん Bさん

シグナリングサーバ

シグナリング

メディアプレーン

つながらないパターン１．シグナリングサーバとの接続（だいたいWSS）ができない

理由：WebSocket禁止、プロキシサーバ有り（法人ユーザに多い）

解決策１：疎通できるようにネットワークのポリシー変更

解決策２：イントラネット内にシグナリングサーバを立てる

つながらないパターン２．メディアの通信（P2P）が疎通できない

理由：NATタイプがセキュア、 P2PやUDP通信が禁止されている

解決策１：疎通できるようにネットワークのポリシー変更

解決策２：TURNサーバを用意する

ICEWebRTCではICEというプロコルを用いてP2P通信の経路を確立する

その際に利用されるユーティリティがSTUNサーバ、TURNサーバである

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アドレスとポート番号の両⽅が含まれる

参考：UDPホールパンチング

NAT NAT

STUNサーバ

参考：UDPホールパンチング

NAT

STUNサーバ

NAT

NATの外側のIPアドレスポート番号が知りたい

111.111.111.11150000番

参考：UDPホールパンチング

NAT

STUNサーバ

NAT

NATの外側のIPアドレスポート番号が知りたい

222.222.222.22255000番

IP : 111.111.111.111Port : 50000

参考：UDPホールパンチング

NAT

STUNサーバ

NAT

IP : 222.222.222.222Port : 55000

IP : 111.111.111.111Port : 50000

ICE候補としてシグナリングで交換

参考：UDPホールパンチング

NATNAT相⼿のIP・ポートに向かってUDPパケットを送信

⽳が開く（折り返しが受けられる）

よくわからない通信は落とされる

IP : 222.222.222.222Port : 55000

IP : 111.111.111.111Port : 50000

参考：UDPホールパンチング

NATNAT

折り返し⽤の⽳を上⼿く通過する

⽳が開く（折り返しが受けられる）

相⼿のIP・ポートに向かってUDPパケットを送信

IP : 222.222.222.222Port : 55000

IP : 111.111.111.111Port : 50000

相⼿に届く（以後双⽅向で通信できる）

ICE• UDPホールパンチングできるNATの種類には制限がある

NATType

フルコーン 制限付きフルコーン

ポート制限付きフルコーン

シンメトリック

フルコーン 可 可 可 可制限付きフルコーン

可 可 可 可

ポート制限付きフルコーン

可 可 可 不可

シンメトリック

可 可 不可 不可

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クライアント(ブラウザ)

通信するための準備

ICE• TURN• UDPホールパンチングで通信ができない場合にメディアを中継する

• FW等でUDPパケットの通信が禁止されている場合にも有効

TURNサーバ

Aさん：TURNクライアント(ブラウザ)

①Create Permissionリクエスト（★のアドレスを使ってBさんと通信したいので許可をください）

③メディアを流すと中継してくれる

Bさん：TURNクライアント(ブラウザ)

準備が整ったら許可を求める

メディアが中継される

参考：TURN通信パターン

•WebRTCにおけるTURN通信は2パターンある（その１）

TURNサーバ

Aさん：TURNクライアント

Bさん：TURNクライアント

TCP通信

Listening AddressIP : 111.111.111.111Port : TCP 3478

UDP通信

Relay AddressIP : 111.111.111.111Port : UDP50000

参考：TURN通信パターン

•WebRTCにおけるTURN通信は２パターンある（その２）

TURNサーバ（複数台のサーバをリレーする場合もある）

Aさん：TURNクライアント

Bさん：TURNクライアント

Listening AddressIP : 111.111.111.111Port : TCP 3478

Listening AddressIP : 111.111.111.111Port : TCP 3478Relay Address

IP : 111.111.111.111Port : UDP 50000

TCP通信 TCP通信

UDP通信 UDP通信

Relay AddressIP : 111.111.111.111Port : UDP 55000

UDP通信

つながらない問題を切り分ける

デバッグ方法

ブラウザデバッグツールを活用する

• Chromeがおすすめ

• chrome://webrtc-internals

デバッグ方法

ネットワーク関連の情報（よく使う項目）

項目 意味

timestamp タイムスタンプ現在利用しているTransportかどうかはこのタイムスタンプが更新されているかどうかで判断

googxxxxAddress ローカル・リモートそれぞれのIPアドレスとポート番号

xxxxCandidateId ローカル・リモートそれぞれで採択されたCandidate情報のID※1（通信するためのIPアドレス、ポート番号等の候補情報）このIDでサイト内を検索すると詳細が確認できる

googxxxxCandidateType ローカル・リモートそれぞれのCandidateタイプrelay : TURN経由の接続

それ以外 : TURNを使用せずにダイレクト接続

デバッグ方法

メディア関連の情報

項目 意味

msidMediaStreamIDでAudioTrackとVideoTrackを束ねた１つのStreamを指すJavaScriptから識別することができる

timestampタイムスタンプ有効なTrackかどうかはこのタイムスタンプが更新されているかどうかで判断

bytesSent 送受信バイト数

mediaType audio/video

packetsLost パケットがロストした場合に表示される

ssrcSynchronisation Sourceという。ここではRTP（リアルタイムプロトコル）で利用する識別子

transportId先程見た Conn-xxxx-x-x に該当このTrackがどのTransport（輸送路）を利用しているかわかる

googCodecName 使用しているコーデック

googTrackId TrackIDでJavaScriptから識別することもができる

デバッグ方法

メディア関連の情報

��������� ��

320x240/10fps

640x480/30fps

1920x1080/30fps

これらの情報を参考に原因究明と解決策を見出す

6. プラットフォームサービスは積極的に活用しよう

WebRTCは総合格闘技

WebRTCは導入は簡単です。でも、本格的に使う場合、全て自分でやるのは地獄を見るかもしれません…

WebRTCを自分で全て開発する場合

WebアプリiOSアプリ

アプリ

Androidアプリ

クラウド

iOS Android Windows Mac

ブラウザ

iOSSDK

AndroidSDK

JavaScript SDK

クラウド

SignalingAPI

STUNAPI

TURNAPI

HTML5 API群

WebRTC プロトコル・スタック

自分で開発・用意 第三者が提供

デバイス側 クラウド側

通信

SFUAPI

プラットフォームサービスを活用する場合

WebアプリiOSアプリ

アプリ

Androidアプリ

クラウド

iOS Android Windows Mac

ブラウザ

iOSSDK

AndroidSDK

JavaScript SDK

クラウド

SignalingAPI

STUNAPI

TURNAPI

HTML5 API群

WebRTC プロトコル・スタック

自分で開発・用意 第三者が提供

デバイス側 クラウド側

通信

プラフォーム事業者が提供

SFUAPI

プラットフォームサービスOpenTok

tokbox

SFUを利用した多対多配信が特徴

CafeXCafex Communications

LiveAssist等のWebRTC対応コンタクトセンターソリューションを提供

プラットフォームサービスSkyWay

NTT Communications

⽇本企業で唯⼀のプラットフォームサービス、トライアル中は無料

Twilliotwillio

SIPとWebRTCを中継するSBC機能が特徴

プラットフォームサービスFacePeerFacePeer

BtoBtoC向けのビデオチャットプラフォームを提供

ミドルウェアWebRTC SFU Sora

時⾬堂

国産ソフトウェアベースのSFUを提供

是非有効活用してみてください

注意プラットフォームサービスを利用しても、つながらない問題とかが全て解決するわ

けではありません

WebRTCを利用した開発の勘所、つかんでもらえましたか？

最後にちょっと宣伝させてください

SkyWayは個人やスタートアップ向けに無料枠が有ります。

とりあえず使ってみてください。

SkyWay Developer Meetup #1

■日時 ： 2017年9月29日（金）18:30開場 19:00開始■会場 ： いいオフィス 東京都台東区東上野2-18-7共同ビル3F■定員 ： 200名■参加費： 無料/登録制 事前登録はこちら※詳しくはイベントサイトをご覧ください。https://skyway.connpass.com/event/65697/

ご清聴ありがとうございました！