本日、次のWebRTCトレンドに関する翻訳を公開します。これはコンサルタントのTsahiに感謝します。 WebRTCテクノロジーの変化はVoIPの世界にもたらしたものであり、統計へのアプローチはどのように変化していますか。 ちなみに、Tsakhi Levent-LevyがIntercom 2017カンファレンスに来たことを覚えているかもしれません。そして彼はWebRTCの歴史と現代のコミュニケーションへの影響についてのレポートを読みました。 ただし、 最も近い会議では 、残念ながらそうではありません。 しかし、bloggeek.meブログは常に利用可能であり、翻訳でさらにアクセスしやすいようにしています:)だから、クライアントからのビデオ通話から統計を収集することについて話しているので、猫の下でお願いします。
WebRTC統計を収集するために、監視はサーバーからクライアント側に移行しています。
WebRTCは、VoIPに関連するすべてを分散化します。 バックエンドの重要性は、エンドデバイスの重要性に屈し始めます。 WebRTCは他のVoIPソリューションと特に違いはありませんが、WebRTCを使用し、まったく異なる方法で使用するサービスを設計しています。
主な例-グループコールの場合、フォーカスをミキシングMCUモデルからSFUルーティングモデルにシフトしました。 そして、突然-MCUを展開したいという欲求がばかげて見え始めました。 私が話していることはわかっています-私は、コールの60％以上がMCUを経由する会社で働いていました。
SFUへの移行は、（MCUを使用してバックエンドでこのハードワークを行うのではなく）エンドデバイスの機能とパフォーマンスにより依存し、ディスプレイをマークアップするためのより多くの特権を与えることを意味します。 次のステップは多重接続ネットワークになりますが、近い将来に実装されるとは思いません。
実際、私が導き出したのは、VoIPパフォーマンス統計（より正確には、WebRTC統計）でも同様のことが起こります。 バックエンドでの統計情報の収集は停止しますが、ブラウザ/デバイスから直接取得することを好みます。
統計収集とVoIP監視
統計情報の収集とVoIPの監視に慣れていない場合、簡単な説明を次に示します。
VoIPは互換性に基づいています。 開発者は製品を作成し、仕様に従って、互換性のためにテストします。 次に、展開に関与する人々は、サービスを収集して実行します。 これにより、1つのベンダーが使用されることがありますが、多くの場合、異なるベンダーの製品が同じアセンブリで動作します。
監視の方法や、どの統計が収集できる/すべき/すべきかについての仕様や標準はありません。 統計を収集する方法はいくつかありますが、最も一般的なのはHEP / EEPを使用する方法です。 仕様にあるとおり：
「拡張可能なカプセル化プロトコル（「EEP」）は、UDP経由で送信される新しいIPデータグラム内に元のデータグラムとその関連ヘッダープロパティ（ペイロードとして、連結チャンクの形で）をカプセル化することにより、IPデータグラムをコレクターに複製する方法を提供します/リモートコレクション用のTCP / SCTP接続。 カプセル化により、元のIPデータグラムとヘッダーのコンテンツを変更せずに元のコンテンツを送信でき、追加の任意のデータを含む追加のチャンクを柔軟に割り当てることができます。 この方法は、ネットワークセグメント上でのIPデータグラムの「トンネリング」用に設計または意図されたものではなく、リモートまたは集中収集および長期保存および分析を目的としたパケットの受動複製のベクトルとして最適です。簡単な言語：メディアパケットは、監視サービスに分析のために複製を送信するために複製されます。
パケットの複製は、VoIPネットワークのメディアサーバーを介してバックエンドで行われます。 これは、 HOMER / SIPCAPTURE Webサイトでの例です。
HOMERは、サーバー（OpenSIPS、FreeSWITCH、Asterisk、Kamailio）から直接データを受信します。これらはユーザーデバイスではなく、バックエンドサーバーのみです。
他のシステムはスイッチ、ルーター、およびネットワークデバイスに依存しており、これらもまたバックエンドインフラストラクチャにあります。 VoIPネットワークでは、ほとんどの場合バックエンドサーバーを介してメディアを送信するため、ここではユーザーデバイスからよりもデータの収集が簡単であると考えるのが論理的です。
これは正常に機能しますが、WebRTCには必要ではなく、有用でもありません。
WebRTC統計の収集と監視
WebRTCで動作するブラウザは少なく（正確には4つのブラウザ）、それらはすべて同様のAPI（実際にはWebRTCで動作します）で動作します。 これらのブラウザーには、 chrome：// webrtc-internalsと同じものを返すgetstats（）メソッドがあります。
多くの実装はピアツーピアで、メディアが送信されます
バックエンドに影響を与えることなく、インターネット経由で直接。 Googleハングアウトは 2年前にこれを開始しました 。 Jitsiサービスは、この機能をJitsi P2P4121という名前で追加しました 。 これらのサービスは、ユーザーの品質をどのように監視しますか？
他のサービスを見ると、それらはほんの数年前のものであることがわかります。 そして、WebRTCはすでに6歳です。 したがって、誰もがすでに機能と安定性に注目しています。 品質と監視はもはや注目されていません。
これは、WebRTC上のアプリケーションがブラウザおよびエンドデバイスから直接統計を収集し、メディアサーバーから統計を取得しようとしないという事実につながりました。
最終結果は？ オープンソースプロジェクト-たとえば、 rtcstats-およびcallstats.ioのような商用サービス。 これらはWebRTC統計（1〜数秒の間隔でgetstats（）APIを使用して収集）に基づいており、監視のためにサーバーに送信されます-統計が収集、保存、分析されます。 testRTCで同様のスキームを使用して、測定結果を収集、分析、視覚化します。
これにより何が得られますか？
- エンドユーザーには正確なパフォーマンス指標があります-統計はクライアントデバイスから収集されるため、バックエンドによる情報の損失はありません。
- 情報の収集には統一された方法が使用されるため、情報に簡単にアクセスできます。 さらに、WebRTCを使用するネイティブのモバイルおよびデスクトップアプリケーションに埋め込むことができます。
- エンドデバイスへの信頼は、どこでも見られるWebRTCのトレンドです。
次は？
WebRTCは、VoIPネットワークについて考えることに慣れている方法で大きく変化しています。 具体的には、統計の収集に関するアプローチ、これが行われる理由、および方法-これについて活発に議論されているとは思わなかったので、話したいと思いました。
これには3つの理由があります。
- ここ数日私にこれを尋ねてきた人もいるので、詳細な答えを書くのは理にかなっています。
- testRTCでは、「ローカル」パッシブモニタリングサービスの提供を検討しています。 サードパーティのクラウドサービスに提供せずにWebRTC統計を収集、保存、分析したい場合は、 当社までご連絡ください 。
- 私のオンラインWebRTCコースは現在更新中です。また、新しいセミナーを準備しています。 それは4月になります（公開当日、コースは2017年9月に更新され、ウェブサイトbloggeek.meの詳細- 翻訳者のコメント ）。 WebRTCを学びたい場合は、コースにサインアップしてください。