Help us understand the problem. What is going on with this article?

WebRTC Update 2016 Summer

More than 3 years have passed since last update.

WebRTC Update 2016 Summer

by yusuke84
1 / 102

はじめに

この資料は HTML5 Confrence 2016 の講演資料です。


自己紹介


スペシャルサンクス

  • この資料を作るにあたりサポートしてくれた、同僚の@iwashi86氏に感謝

講演のターゲット


ターゲット

  • WebRTCを使ってみたいと考えているWebエンジニアの方
  • WebRTCを実際に使っているWebエンジニアの方

では、始めます


HAPPY BIRTHDAY


HAPPY BIRTHDAY

  • WebRTCは今年で誕生5周年

webrtcorg.png


WebRTCの登場


5年間でWebRTCはどれだけ成長したのか?

  • 全世界でWebRTC対応ブラウザは約2億台以上稼働
  • Chromeでは1週間に
    • 10億分のビデオストリームがやり取りされている
    • 500TB以上のデータがDataChannelでやり取りされている
    • (感想:Chromeって利用状況かなり細かく計測してるんですね)
  • 2016/6/9時点で951のWebRTCに関するプロダクトやベンダーが活動
  • Facebbokメッセンジャーやハングアウト等、Android/iOSでWebRTC機能が実装されたアプリのダウンローヅ数は数十億規模

WebRTCを取り巻く環境の変化

  • TwillioやToxbox、AT&T、シスコなどが開発者のためのプラットフォームサービスを提供
  • GoogleはWebRTCにロイヤリティフリーのコーデック(OpusやVP8)を提供
    • 音声通信の約80%はOpus
    • VP9が最近登場しVP8よりも通信料を約30%削減可能(代わりにCPU使用率は上がる)
  • Alliance for Open Mediaは業界横断的にロイヤリティフリーのコーデックの品質改善のために活動している

これから成し遂げたいこと

  • オーディオとビデオの品質改善、相互運用性向上
    • (感想:H.264の相互接続等課題多い印象)
  • ネットワーク要件(LTE普及によるモバイル環境での利用シーン増加等)の変化への追従
  • Web以外への適用領域への展開(例えばVRと組み合わせとか)

WebRTC☓コミュニティ

  • WebRTCの開発にコミュニティは必要不可欠な存在になっている。
  • オープンな場で開発を行うことの価値を証明した。
  • 今後もWebRTCが利用できることの価値は時間とともに成長していく。
  • これは始まりにすぎない。

あれ、ちょっと待てよ…


「これは始まりにすぎない」


WebRTC辛い…_| ̄|○

  • 去年話題になったフレーズ
  • なぜ辛いのか?
    • ブラウザの実装やOSSのWebRTCスタックに対しては日々変更が入る
    • 破壊的な変更もあったりして、サービス運営側は大変 等等

  • 社内の一例(libwebrtcのコミットログウォッチとか・・・)

libwebrtc.png


しかし、WebRTCは進化する

いずれは、WebRTCはリアルタイムコミュニケーションのスタンダードになるだろう


民主化1.png


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

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

民主化2.png


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

  • 2000年前後に、NapsterやSkypeがインターネット上でリアルタイム・コミュニケーションを実現

民主化3.png


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

  • 2011年にWebRTCの最初の草案が発表
  • 全てのソフトウェアエンジニアがリアルタイムコミュニケーションを扱える時代が到来
  • リアルタイムコミュニケーションの民主化が始まった

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

  • 市場のニーズは確実にある
  • サービスを開発するものとしては避けては通れない

開発者はどうするべきか?

  • 技術の進歩をウォッチ
  • 適宜開発に取り入れる
    • 今の段階で、一度決めたら仕様変更NGな案件には使いにくいかも
  • 辛いので開発者支援サービスは積極的に使いましょう
    • 辛さはみんなで分かち合えば乗り越えられる

今日みなさんにお伝えすること

  • WebRTCの最新動向(いろいろな切り口から)
  • WebRTCを利用する上で知っておいて欲しい技術的なトピックス

ゴール(皆さんに達成してもらいたいこと)

  • WebRTC界隈のトレンドをざっくり把握した気になる
  • WebRTCを利用したくなる
  • WebRTCに関する様々な情報の調べ方が身につく

WebRTC概要


WebRTC概要

  • 知識レベルを合わせるために概要を少し紹介

WebRTC概要

WebRTCでできるようになる事

  1. ブラウザ間で直接通信ができる
  2. ストリーミングデータを扱える
  3. カメラとマイクが使える

image


WebRTC概要(基礎編)

WebRTCはリアルタイムコミュニケーションのオープン標準技術

  1. ライセンス料やパテント料が不要
  2. 技術の中身は4つ(ざっくり)
    1. 暗号化、到達・順序保証、流量・輻輳制御を実現
    2. NATを超えてP2P通信をする手順を確立
    3. オーディオとビデオのコーデックを規定
    4. JavaScriptから利用できるブラウザAPIを提供
  3. ブラウザとネイティブアプリの両方で利用可能
    • Googleが中心となって公開するOSSのスタック(C++製を利用し、コンパイルすれば、ネイティブアプリを始め様々な環境にWebRTC機能をインストール可能
      • Chromeの実装もこれがベースになっている
      • 既存の電話のようなレガシー技術から今話題のIoT等、新旧問わず相性が良い

WebRTC概要(基礎編)

WebRTCの対応状況

Windows Mac Android iOS
Chrome :o: :o: :o: :x:
Firefox :o: :o: :o: :x:
IE :x: - - -
Edge :o: - - -
Safari - :x: - :x:
NativeApp :o: :o: :o: :x:
  • IE: プラグイン利用が必須
  • Edge: 現在対応中(詳しくは後述)
  • Safari: Ericssonが WebRTC in WebKitプロジェクトを立ち上げ、開発を支援。WebKitへの実装が進められている

WebRTC概要(詳細編)


WebRTCの技術的習熟度


WebRTCの技術的習熟度

  • 有名なガートナーレポートによれば
    • 2016年版では流行期(Peak of Inflated Expectations)の終盤
    • 流行期とは?
      • 世間の注目が大きくなり、過度の興奮と非現実的な期待が生じることが多い。成功事例が出ることも多いが、多くは失敗に終わる。 wikipediaより

WebRTCの技術的習熟度

  • 安定期までは2年〜5年
    • 2015年から同じステータスなのであと1〜4年位かな?

WebRTCの標準化の仕組み


標準化の役割

  • WebRTCの全体アーキテクチャや各種プロトコルはIETFで標準化
  • Webブラウザに搭載されるAPIはW3Cで標準化

IETFでの標準化

  • WebRTCの全体アーキテクチャや各種プロトコルはIETFで標準化 image

IETFでの標準化

  • 細かい話が多く且つ、今日ご参加の皆さんには正直あまり関係のない話なので、同僚の@iwashi86氏の「勉強会資料 - 2016/8月時点 WebRTCの標準化動向からいくつか」から例を一つご紹介

    • ICE Network Cost(draft-thatcher-ice-network-cost-00)
      • ICEで収集した通信経路情報にネットワークコスト情報(算出方法は実装依存)を付加し、このコストを加味して通信経路を選定できるようにする
  • WebRTCの技術要素の殆どがIETFで議論されているので興味がある方はウォッチしてみるとよいのでは


W3Cでの標準化

  • Webブラウザに搭載されるAPIはW3Cで標準化 image

W3Cでの標準化

  • ORTCという兄弟仕様もあり image

W3Cでの標準化

WebRTCとORTCという2つの仕様についての今後の展望(個人の所感ですが)


W3Cでの標準化

  • WebRTC Working Groups
    • 現在のWebRTC1.0の仕様をFIXするために粛々と作業している
    • 実際問題遅れまくりだけど・・・

W3Cでの標準化

  • ORTC Community Groups
    • こちらは次世代のRTC APIを作るために議論を行っている
    • Community Groupsは公式な仕様書を作ることができないので、議論した成果はWebRTC WGの方にインプットされていくはずである
    • 実際にWebRTC WGはORTC CGでの検討結果を適宜取り入れている
      • RTCRtpSender / RTCRtpRecevicer
    • WebRTC開発者としては、WebRTCの仕様をウォッチしておけば事足りる
      • 厳密にはWebRTC WGの仕様とブラウザの実装をウォッチする必要があるけど・・
    • MS EdgeがWebRTC1.0対応を表明しているため、今後現実世界でORTCを利用するシーンは無い(はず)

API仕様でチェックしておくポイント


注意

  • ブラウザに実装されていないAPI、ブラウザの実装が先行しているため独自実装なAPIが多々あるので、注意
  • 新しい情報と従来からの情報が混じってますが、特に区別する必要性がないため注釈等はなし

W3CのExamplesを例にご紹介

var signalingChannel = new SignalingChannel();
var configuration = { "iceServers": [{ "urls": "stuns:stun.example.org" }] };
var pc;

// call start() to initiate
function start() {
    pc = new RTCPeerConnection(configuration);

    // send any ice candidates to the other peer
    pc.onicecandidate = function (evt) {
        signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
    };

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

    // once remote video track arrives, show it in the remote video element
    pc.ontrack = function (evt) {
        if (evt.track.kind === "video")
          remoteView.srcObject = evt.streams[0];
    };

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

signalingChannel.onmessage = function (evt) {
    if (!pc)
        start();

    var message = JSON.parse(evt.data);
    if (message.desc) {
        var desc = message.desc;

        // if we get an offer, we need to reply with an answer
        if (desc.type == "offer") {
            pc.setRemoteDescription(desc).then(function () {
                return pc.createAnswer();
            })
            .then(function (answer) {
                return pc.setLocalDescription(answer);
            })
            .then(function () {
                signalingChannel.send(JSON.stringify({ "desc": pc.localDescription }));
            })
            .catch(logError);
        } else if (desc.type == "answer") {
            pc.setRemoteDescription(desc).catch(logError);
        } else {
            log("Unsupported SDP type. Your code may differ here.");
        }
    } else
        pc.addIceCandidate(message.candidate).catch(logError);
};

function logError(error) {
    log(error.name + ": " + error.message);
}

RTCPeerConnectionのConfuguration

var configuration = { "iceServers": [{ "urls": "stuns:stun.example.org" }] };
var pc;

// call start() to initiate
function start() {
    pc = new RTCPeerConnection(configuration);
  • 設定可能な項目
項目 意味
iceServers STUN/TURNサーバのURLを指定
iceTransportPolicy relay: P2PによるIPアドレスの漏洩等を防ぐ場合にTURNサーバ利用を強制する
all: 全ての通信経路候補から選択する
bundlePolicy audio,video,dataを一つの通信経路上(=特定のIP/Port-IP/Port)で送信する仕組み(bundle)のポリシーを決める。bundleに対応していないクライアントが来た場合にどうするかを決める
rtcpMuxPolicy RTPとRTCPを同一通信経路でやり取りする仕組みのポリシーを決める。rtcpMuxに対応していないクライアントの場合にどうするかを決める
require(rtcpMux必須)を選ぶと、生成されるcandidateの数が半分になる

createOffer

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

  • APIのコールバックはPrimise仕様に変わっている
    • createOfferについては、Firefoxが昨年、Chromeがつい最近対応済み
  • pc.onnegotiationneeded 大事!
    • Offer/Answerの発火タイミングをブラウザが支持してくれる
    • addStream / removeStream 等を利用する場合は必須

ontrack

    // once remote video track arrives, show it in the remote video element
    pc.ontrack = function (evt) {
        if (evt.track.kind === "video")
          remoteView.srcObject = evt.streams[0];
    };

  • pc.onaddStream というイベントが有ったけど、あちらはもうオワコン
  • WebRTCの世界はStreamをTrack単位で扱う方向に変わってきている
    • pc.ontrack は大事

Trackとは?

  • WebRTCにおける通信経路の概念図

image


getUserMedia

    // 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);
  • getUserMediaDevice and Sensors WGWebRTC WGの合同TF
  • 仕様書としてはRTCPeerConnectionとは別だが、議論の主導権はWebRTC WGが握っている
  • navigator.getUserMedia()は旧来の仕様なので注意
  • こちらもCallbackのPromise化が進んでいる

今後重要になるAPI仕様


RTCRtpSender/RTCRtpReceiver

  • MediaStreamTrackの送信、受信に関する様々な制御が可能
  • FirefoxにはすでにgetSender/getReceiverが搭載されている
peer.getSenders()
Array [ RTCRtpSender, RTCRtpSender ]

peer.getSenders()[0]
RTCRtpSender { track: AudioStreamTrack }

peer.getSenders()[1]
RTCRtpSender { track: VideoStreamTrack }

RTCRtpSender/RTCRtpReceiver

  • 仕様書通りに実装されれば、例えば、RTCRtpSender.setParametersでコーデックのパラメーター(maxBitratemaxFramerate)等の調整が可能
    • 今はSDPを直接修正するしか無い

RTCRtpSender/RTCRtpReceiver

m=video 9 UDP/TLS/RTP/SAVPF 100 101 107 116 117 96 97 99 98
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Xcn23/VduEyHSDiF
a=ice-pwd:bVgn5UOhyAjHWySy9C0otLmi
a=fingerprint:sha-256 47:6D:93:03:82:4A:22:6F:A2:65:4E:26:7E:D9:ED:0E:51:54:8F:D8:EE:DF:62:C1:36:E4:0C:97:49:32:BE:C3
a=setup:actpass
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=sendrecv
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtpmap:101 VP9/90000
a=rtcp-fb:101 ccm fir
a=rtcp-fb:101 nack
a=rtcp-fb:101 nack pli
a=rtcp-fb:101 goog-remb
a=rtcp-fb:101 transport-cc
a=rtpmap:107 H264/90000
a=rtcp-fb:107 ccm fir
a=rtcp-fb:107 nack
a=rtcp-fb:107 nack pli
a=rtcp-fb:107 goog-remb
a=rtcp-fb:107 transport-cc
a=fmtp:107 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=rtpmap:96 rtx/90000
a=fmtp:96 apt=100
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=101
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=107
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=116

RTCRtpTransceiver

  • setCodecPrefencesでコーデックの種類を指定できる
  • setDirectionでメディアの方向、活性非活性を設定可能
    • sendrecv : 送受信
    • sendonly : 送信のみ
    • recvonly : 受信のみ
    • inactive : 非活性
  • 現状はcreateOffer / createAnserのオプションであるofferToReceiveVideo / offerToReceiveAudioで設定

RTCRtpTransceiver

  • offerToReceiveVideo / offerToReceiveAudioと方向の組み合わせ
それぞれの値 Offer側のSDPの方向 Answer側のSDPの方向
true sendrecv sendrecv
true sendrecv sendrecv
false sendonly recvonly
false sendonly recvonly
  • Offer側に依存する
  • ディフォルトは true
  • inactiveの使いドコロは?
    • 途中でメディアの送信を止めたい場合
    • MultiStream時に途中で参加者が離脱した場合
    • トランスポートのウォームアップ

覚えておいたほうがいい仕様


RTCIceTransport

  • P2Pのコネクションを管理する
  • そもそもICEとは?
    • ICE(Interactive Connectivity Establishment, RFC5245)
    • STUN/TURNといったプロトコルを利用してNATを超えるための手順が規定されている

RTCIceTransport

ICEについておさらい

  • シグナリングを通して収集したCandidate(後述)の情報を元に通信可能かどうかを試行する

  • 試行にはUDPホールパンチングという手法を用いる(ここでは割愛)

image


RTCIceTransport

RTCIceTransportState

  • 接続の試行はステータス管理されている

icetransportstate.png
引用元:https://www.w3.org/TR/webrtc/#idl-def-rtcicetransport

  • ポイントは dissconnected
    • 通信状態が悪いなどでdissconnectedになった場合は勝手に再接続する
      • モバイル環境やwifiと3gの切替時には重宝する機能可能性がある
    • failedになると失敗する(通信断)

RTCIceCandidate

Candidateについておさらい

  • Candidateは通信を試行するための各種情報の集まり
candidate:3692472706 1 udp 2122260223 192.168.1.1…eration 0 ufrag ot0u network-id 1 network-cost 10
  • 含まれている主要なもの
    • プライオリティ(接続優先度)
    • IPアドレス
    • プロトコル(tcp/udp)
    • ポート
    • タイプ(次頁)
    • network-cost(Chromeのみ、最近つくようになったはず)

RTCIceCandidate

タイプ 意味合い
host NICから得られるアドレス
srfix STUNによって得られるNATの外側のアドレス
prflx UDPヒールパンチング中に発見したアドレス
relay TURNに対しての接続が許可された時に取得できるアドレス
  • どういう経路でP2Pの通信が確立したかを確認したり、逆に通信経路を限定したりいろいろとできる

RTCIceCandidate

ティップス:IPリーク問題


RTCStats

var baselineReport, currentReport;
var selector = pc.getSenders()[0].track;

pc.getStats(selector).then(function (report) {
    baselineReport = report;
})
.then(function() {
    return new Promise(function(resolve) {
        setTimeout(resolve, aBit); // ... wait a bit
    });
})
.then(function() {
    return pc.getStats(selector);
})
.then(function (report) {
    currentReport = report;
    processStats();
})
.catch(function (error) {
  log(error.toString());
});


RTCStats

  • chrome://webrtc-internalsのような情報をプログラム側から収集可能
  • 現在のAPI実装はブラウザの独自実装
  • callstats.ioのようなStatsを収集してくれるサービスも有る
  • 実装したイメージ(次頁)

webrtc-stats.png


API仕様の話はこれで終わりです


最近のブラウザアップデート状況


Chrome


Chrome(M49〜M53)

独自仕様でガンガンいろいろなものを入れてくる

  • MediaRecoder APIサポート
    • ブラウザ上で映像音声の録音が可能に
    • 公式デモ
  • Remote Audio TrackをWebAudioAPIやMediaRecoderAPIで操作可能に
  • DTLSのハンドシェイク等にECDSA証明書が利用可能になった
    • それまではRSA証明書のみ
  • ECDSAベースの証明書生成にも対応

Chrome(M49〜M53)

  • H.264対応
    • M50でフラグ付き
    • M51でFirfoxとの相互接続性を向上
    • M52でフラグなしの正式サポート
  • Opusがv1.1からv1.1.2へアップグレード
  • Audio Screen Shareに対応
    • WindowsとChromeOSに限定されるが、システムオーディオをシェア可能
  • Canvas Caputure Streamに対応
    • Canvasの映像からMediaStreamを生成し送信することが可能
  • pc.createOffer()のpromise対応
  • AndroidにてCamera 2 APIをサポート(パフォーマンス向上)
  • navigator.webKitGetUserMediaのベンダープレフィックスを削除
  • navigator.mediaDevices.getUserMedia()に対応

Firefox(44〜50)

標準仕様に則った地道なアップデートが多い

  • Simulcastの試験実装開始
  • RTCRtpEncodingParametersに対応
  • RTCRtpSender.setParameters()に対応
  • ICE Restart対応
  • MediaRecorder on Androidに対応
  • MediaStream.addTrackイベントに対応
  • MediaStreamTrack.readyState()に対応

ChromeとFirefoxの相互接続

ティップス:MultiStream対応

  • 複数のストリームを同じ通信経路(トランスポート)上でやり取りする場合の方式がChromeとFirefoxで異なる
  • 具体的にはSDPのセッション記述部、メディア記述部の記載が変わる
  • ChromeはPlan B、FirefoxはUnified Planという方式をとっており、将来的にはUnified Planに統一される
  • 現在は、ChromeとFirefoxでマルチストリームの相互接続をするにはSDPの変換が必要

Edge

  • 2015/9 にORTC対応
    • adaptor.jsというshimを使えばChrome/Firefoxと相互接続可能
    • ビデオコーデックが H.264UCのみなので音声のみ
  • 2016/8 にWebRTC1.0の機能が一部実装始めている
    • H.264/AVCの実装も進んでいる

edge-flang.png

  • あと少し!

Safari

  • WebKitの実装は始まっている

webkit-webrtc.png
https://webkit.org/status/#specification-webrtc


WebRTCネイティブアプリアプリ対応


ネイティブアプリアプリで利用する方法はいくつか

  • ハイブリッドアプリ
    • Electron
    • Cordova
  • ネイティブアプリ
    • React-Native
    • libwebrtc(WebRTCのOSSスタック)を自分でビルドして利用する

メディアサーバーの動向


P2PだけじゃないWebRTC

  • WebRTCはP2Pが基本だが、複数人での同時利用や録音録画などを行う場合にメディアサーバー(MCU/SFU) を利用することができる

MCU

SFUMCUイメージ.jpg

  • 全てPeerからのメディアを集約、ミキシングし配信
  • Peerの負荷をMCU側に集約
  • 全てのストリームをエンコード/デコードするため、MCUのCPU性能がボトルネックになる(エンコードを1本化する方式も存在する)
  • トランスコード、オーバーレイ、録画、録音、何でもできる

SFU

SFUMCUイメージ_SFU1.jpg
SFUMCUイメージ_SFU2.jpg

  • 各Peerからのメディアを必要数分複製し配信
  • 配信に必要な帯域の一部(上り分)をSFU側に集約
  • 全てのストリームの復号化/暗号化を行う
  • ストリーム自体に手を加えないがめSFUの負荷は軽い
  • SVC+Simulcastと組み合わせることにより真価を発揮する

SVC+Simulcastとは?

  • 同時に複数のPeerに映像を送る場合、Peer毎に受信環境が違う可能性がある
    • 例えば、自宅PCとLTEスマホ等
  • SVCというコーデックの仕組みとSimulcastを使えば、受信者に合わせた適切な解像度・ビットレートの動画を配信することができる
  • 仕組みがない場合、SFUでは一番低レベルな受信者に合わせることになり、全員の品質を落とすことになる

MCU/SFUの代表的なプロダクト

プロダクト名 SFU MCU 録音・録画 OSS
Intel Collaboration Suite for WebRTC :o: :o: :o: :x:
Janus+Janus VideoRoom plugin :o: :o: :o: :o:
Jitsi VideoBridge :o: :x: :o: :o:
Kurent :o: :x: :o: :o:
Lincode :x: :o: :o: :o:
Medooze :o: :x: :x: :o:
SORA :o: :x: :o: :x:
PowerMedia XMS :x: :o: :o: :x:

プラットフォームサービスの動向


プラットフォームサービスの動向

  • マルチに使えるもの、業界に特化したものいろいろと出ている
  • 是非活用してみてください
プロダクト名 SDK 特徴
TokBox JS/Android/iOS SFUを利用したMediaConnectionのみ提供
Skylink JS/Android/iOS IE/Safariプラグインを提供
ICELINK JS/Android/iOS/Windows/Linux 等 対応プラットフォームが多い
Intel Collaboration Suite for WebRTC JS/Android/iOS/Windows 先述したメディアサーバーやGateWayサービスなども提供
SkyWay JS/Android/iOS 日本語サポートが可能
CafeX JS/Android/iOS コンタクトセンターに特化
Twillio Android/iOS SIP to WebRTCのGateWayを提供

テストサービスの動向


テストサービスの動向

  • testRTC
    • WebRTCのテスト、モニタリング、分析プラットフォーム

WebRTCの情報収集チャネルを紹介


最新のネタを収集したい時は?

  • WebRTC Standard
    • 各ブラウザのアップデート状況や標準化の状況が更新される
    • 頻度高め
  • WebRTC Hacks
    • WebRTCの技術系トピックスが豊富
    • Chad Hart氏が運営
  • bloggeek
    • 技術よりな話題からビジネス寄りな話題まで幅広く載っている
    • Tsahi Levent-levi氏のブログ
  • WebRTC by Dr Alex
    • Alex. Gouaillard氏のブログ
  • WebRTC News   - google news   - Bizよりな情報が知りたいときはチェック

ブラウザのアップデート情報を収集したいときは?


日本語情報を収集したいときは?


最後に・・・


ちょっと宣伝


今日話したこと

  • WebRTC五周年の話
  • 目標設定
  • WebRTC概要
  • WebRTCの技術的習熟度
  • WebRTCの標準化の仕組み
  • API仕様でチェックしておくべきポイント
  • 今後重要になるAPI仕様
  • 最新ブラウザアップデート状況
  • WebRTCネイティブアプリアプリ対応
  • ディアサーバーの動向
  • プラットフォームサービスの動向
  • テストサービスの動向
  • WebRTCの情報収集チャネルを紹介

最後までお付き合いいただきありがとうございます


参考文献

yusuke84
WebRTCに関わり7年目。NTTコミュニケーションズでWebRTCプラットフォームSkyWayのプロダクトマネージャーをやっています。
https://twitter.com/Tukimikage
nttcommunications
NTTコミュニケーションズは、お客さまのデジタルトランスフォーメーション実現に貢献する「DX Enabler™」として、ICTの活用によるお客さまの経営課題の解決やスマートな社会の実現に取り組みます。
https://www.ntt.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away