まずは、webRTCの公式サイトにある図を見て、webRTCのアーキテクチャを理解しましょう：

WebRTCのアーキテクチャの説明については、公式の英語ドキュメントが非常にわかりやすく言っているので、この記事はその翻訳者としての役割の方が大きいかもしれません。以下、WebRTCのアーキテクチャを上から順に説明します。

3層アーキテクチャ

まず図から、webRTCが3つの部分に分かれていることがわかります。緑色の部分、濃い紫色の部分、薄い紫色の部分です。

上部の矢印のある薄紫色の部分は開発者のアプリケーションレイヤーで、開発者がWebRTC仕様に基づいて開発するアプリケーションを指します。厳密に言えば、これはWebRTCアーキテクチャの一部ではありません。

Web API (Edited by W3C WG)WebRTCの濃い紫色の中間層の部分は、アプリケーション層の開発者がAPI（主にWeb用のJavaScript API）を呼び出すために開いている、この層の開発者は、複雑な基礎技術を気にする必要はありません、ちょうどWebRTCプロセスの一般的な原則を理解する必要があり、そのAPIの曲は、WebRTCのピアツーピア通信機能を実現するために使用することができます。

2番目の緑色の部分はWebRTCのコア機能層で、4つのサブコア機能層に分かれています。C++ API層、セッション管理層、エンジン層、ドライバー層です。

Your web app

つまり、矢印のついた薄紫のレイヤーが「Your web app # 1...」です。上述したように、これは厳密にはWebRTCのアーキテクチャの一部ではないので、ここでは取り上げません。

Web API

Your web app # 1...Web API層はまたの深い紫色の部分は、アプリケーション層の開発者のAPI（主にWeb使用のためのJavaScript API）にWebRTCを開くと、この層の開発者は、複雑な基礎技術を気にする必要はありませんが、ちょうどWebRTCの一般的なプロセスの原則を理解する必要があります、APIは、ピアツーピア通信機能を達成するためにWebRTCを使用するように調整することができます。

WebRTC C++ API

Web API (Edited by W3C WG)緑色で包まれた薄紫色の部分は、この部分は主にいくつかのC++インタフェース層であり、この層は、主にブラウザがWebRTC仕様をサポートし、APIを呼び出すために、いくつかのC++ APIを提供し、例えば、Android上でWebRTC機能を実装する必要がある場合は、APIのこの層を呼び出すためにJNI関数を記述する必要があります。 この層の主な役割は、デバイス管理、オーディオおよびビデオストリーミングデータ収集などのWebRTCのコア機能を公開することであり、ブラウザベンダなどの様々なソフトウェアベンダのアプリケーションへの統合を容易にします。このレイヤーの主な役割は、デバイス管理、オーディオおよびビデオストリーミングデータ収集などのWebRTCのコア機能を公開し、ブラウザベンダーのような様々なソフトウェアベンダーの自社アプリケーションへの統合を容易にすることです。

その中でも、PeerConnectionはこのレイヤーの最もコアなモジュール、つまりピアツーピア接続モジュールです。このモジュールには、壁越しのP2P、通信リンクの確立とプリファレンス、ストリーミングデータ伝送、非オーディオ/ビデオデータ伝送、伝送品質レポートと統計など、多くの機能が実装されています。

Session management

Session management / Abstract signaling (Session)緑で示されたレイヤーはセッション管理レイヤーです。このレイヤは、セッションの作成、セッションの管理、コンテキスト環境の 管理などのセッション管理機能を提供します。このレイヤーには、シグナリング相互作用やRTCPeerConnectionの接続ステータスの管 理に使用される、シグナリングサーバーのSDPプロトコルなど、さまざまなプロトコルが 含まれます。

エンジン層

このレイヤーはWebRTCコアレイヤーの中で最も重く複雑なレイヤーです。このレイヤーはVoice Engine、Video Engine、Transportの3つのサブモジュールに分かれています。

最初のモジュールであるVoice Engine（オーディオエンジン）は、オーディオキャプチャ、オーディオコーデック、オーディオ最適化など、一連のオーディオ処理機能を含むフレームワークです。

2番目のモジュールのビデオエンジン（Video Engine）は、ビデオキャプチャ、ビデオの符号化と復号化、ネットワークのジッタに応じてビデオ伝送品質の動的な変更、イメージ処理などの一連のビデオ処理機能を含むフレームワークです。

3番目のモジュールトランスポート（トランスポートモジュール）、WebRTCでは、オーディオやビデオなどのストリーミングデータに加えて、データ伝送だけでなく、ファイル、テキスト、イメージやその他のバイナリデータを転送することができ、これらの機能は、このモジュールによって提供されます。

図からわかるように、各エンジンの下には複数のサブエンジンがあり、各エンジンの下にあるサブエンジンの機能を以下に説明します。

iSAC / iLBC Codec

iSACとiLBCはWebRTCの内蔵オーディオエンコーダーです。iSACはブロードバンドや超ブロードバンド環境でのVoIPや音声ストリーミングの音声伝送のためのコーデックで、WebRTC音声エンジンのデフォルトコーデックです。

NetEQ for voice

NetEQは、ネットワーク音声信号処理のコンポーネントであり、このアルゴリズムは、ネットワーク環境の変化に適応することができ、効果的に音声品質の問題に起因するデータパケットの損失によって引き起こされるネットワークのジッタに対処することができ、この技術は、WebRTC GIPSの合言葉の前身と言うことができます。

Echo Canceler/Noise Reduction

エコーキャンセラーは、効果的に音声キャプチャのエコー効果を除去するエコーキャンセルモジュールであり、例えば、リアルタイムのオーディオおよびビデオ通話の過程で、携帯電話のスピーカーを開き、本来の要求は、リアルタイムで自分の声を録音し、相手に送信することですが、エコーの存在により、それはまた、相手の音声に相手の声を録音します。現在、市販されている携帯電話の録音機能自体にエコーキャンセラーが搭載されているものがあり、Androidでも関連APIが提供されていますが、ほとんどの場合、このAPIが動作しないようで、メーカーの互換性の問題が原因かもしれませんし、直接この機能を去勢している可能性もあります。そのため、全プラットフォームでエコーキャンセレーションを使った録音を行いたい場合は、WebRTCの機能を使うことができます。iOSプラットフォームでの録音はエコーキャンセル付きです。

一方、ノイズリダクションは、広範囲のノイズを効果的に抑制するようなノイズ抑制モジュールです。

VP8 Codec

VP8はOn2ビデオの第8世代であり、より少ないデータ量でより高品質なビデオを提供し、再生に必要な処理能力も低く抑えられるため、製品やサービスの差別化を図るインターネットTV、IPTV、ビデオ会議事業者にとって理想的なソリューションとなります。

そのデータ圧縮率と性能面は、市場に出回っている他のコーデックよりも高く、機能面もリアルタイム通信に適しているため、WebRTCのデフォルトのビデオコーデックとなっています。

VP9は、Googleが提供するオープンソースでフリーのビデオコーデックで、VP8の後継として、当初はNext Generation Open Source VideoまたはVP-NEXTという名称で開発されました。

VP9の開発は2011年第3四半期に始まり、同じ品質を維持しながらVP8のビットレートを50％削減する試みと、VP9がH.265よりもエンコード効率が良くなることを期待していました。

Video Jitter Buffer

ビデオジッタバッファ - ビデオジッタバッファは、リアルタイムのビデオ通信は必然的にビデオジッタやビデオデータの損失につながるネットワークの理由に起因することになり、ビデオジッタバッファは、効果的に大きな影響によって引き起こされるライブ会議の品質にそのような状況を解決するために独自のアルゴリズムに依存しています。

Image enhancements

mage enhancements - 画質向上モジュール、このモジュールは、イメージの明るさ検出、色強調、ノイズ除去処理など、ビデオ画面の品質を向上させるイメージ処理を行うために使用されます。

SRTP

SRTPはトランスポートモジュールに属し、SRTPを理解するにはまず RTPを理解する必要があります。

RTPは、リアルタイムの特性を提供するエンドツーエンドのデータ転送サービスプ ロトコルです。RTCPと一般的に呼ばれる他のプロトコルは、RTPの制御プロトコルです。

RTPは、httpやftpなどのようなものではありません全体の映画やテレビのファイルをダウンロードすることができます、それは、RTPのいくつかのバイトのヘッダが何を示す場合は、ネットワーク上のデータを送信する固定データ形式である、オーディオデータやビデオデータは、これらのバイトでは、RTPに含まれているデータなど。

RTPでは、暗号化機能がないなど、データ伝送のセキュリティが考慮さ れていないため、セキュリティ要件の高いアプリケーションのニーズを満たす ことができません。SRTP（SecureReal-time Transport Protocol）は、RTPをベースにセキュリ ティメカニズムを追加したトランスポートプロトコルであり、データの暗号化、メッ セージ認証、完全性の保証、およびリプレイ保護を提供し、データ伝送のセキュリ ティを最大化します。つまり、RTPとSRTPの関係は、おそらくhttpとhttpsの関係です。

Multiplexing

マルチエクシング、チャネル多重化、すなわち、伝送効率を向上させるために、データ伝送の複数のストリームが共通のチャネルを共有します。

正直なところ、今のところ筆者はこれがどのように多重化されているのか理解できていないので、ひとまず置いておきましょう。

P2P STUN+TURN+ICE

WebRTCがP2Pベースの通信技術であることは既に述べた通りです。そして、STUN、TURN、ICEはP2Pを実現するための重要な技術です。

STUN、TURN、ICEとNATの浸透になると、実際の生活の中で、内部と外部のIPの異なるLANが直接通信することはできません、例えば、192.168.2.1のLAN Aと192.168.2.2のLAN Bはお互いに直接送信することはできませんので、2つの異なるLANで直接通信チャネルを確立したい場合は、STUN+TURN+ICEに依存する必要があります。STUN+TURN+ICE に頼らなければなりません。

そして、STUN、TURNとICEは、浸透のために異なるスキームを使用している、これは3つの単語が明確に言うことができない、後で詳細に理解するために例と組み合わせることができます。

ドライバー層

まとめ

WebRTCの優れたレイヤー設計から、少なくとも私たちは、優れたアーキテクチャ設計のほとんどが分割統治を行うことを学びました。各レイヤーは小さなファンクションポイントであり、各レイヤーを十分に良くし、各レイヤーを最適に組み立てることで素晴らしいプロジェクトができるのです。

WebRTCは、実際には非常に大きなコンテンツであり、各モジュールを行うことができれば、十分に良い、十分に最適化され、さらにはプロのプロジェクトの操作を行うために別々に抽出することができます。WebRTCを深く勉強するのに、どれだけのエネルギーと時間がかかるか想像できます。

オーディオとビデオに基づいて構築されたプロジェクトのWebRTCのほとんどは、通信を学ぶことに関連する知識を理解する必要があるだけでなく、オーディオとビデオに関連する知識を必要とするだけでなく、この知識は、実用的な多数の必要性であるを介して食べたい、あなたは彼らが知っていることを知るためにやりたい場合は、その後、子供の靴だけでなく、継続的な学習のああ持久力の強いセルフコントロールを持っている必要があります。

WebRTCライブオーディオ/ビデオ通信技術。

私についてきて、一緒に進歩しましょう！人生にはコーディング以上のものがあります！