WebRTC技術の話題②【時代の流れ、WebRTCを知る第一歩】

今日の一文

人生の課題はどこにでもあり、自信に満ち、道は明るく、明日は常に希望に満ちた戦場です。

上記を引き受けるために

上記の内容に着手し、関連する WebRTC 技術の概念と開発履歴を紹介した後、関連する WebRTC 技術の機能と原理の調査を開始しました。

テクニカルレビュー

WebRTCの概念定義

WebRTCという名前は、Web Real-Time Communication(Web Real-Time Communication)の略語に由来し、リアルタイムの音声会話やビデオ会話をWebブラウザーに対応させる技術です。

WebRTCの機能範囲

• WebRTC は、ブラウザーがリアルタイム通信 (RTC) 用のシンプルな JavaScript インターフェイスを提供できるようにすることを目的としたオープン ソース プロジェクトです。

• WebRTC は動画だけでなく、テキストや画像などの他のデータも送信できます。WebRTC はブラウザーのサブセットではなく、ブラウザーは WebRTC の標準プロトコルに従って WebRTC のネイティブ インターフェイスのみを実装することに注意してください。Android および IOS システムも WebRTC をサポートしています。

WebRTC アプリケーションには、次の 4 つの主要な概念が含まれます。

• シグナリングサーバー

• ICE サーバー

• メディアサーバー

• JavaScript インターフェイス (JavaScript API)

WebRTC は HTML5 標準に含まれています

現在 WebRTC プロトコルをサポートしているブラウザは次のとおりです: Chrome、Firefox Opera、IE はサポートしていません~

• WebRTC は特定のシグナリング プロトコルを指定しておらず、特定のシグナリング プロトコルはアプリケーションの実装に任されています。

• WebRTC は JSEP プロトコルを使用してセッションを確立します。

• WebRTC は ICE を使用して NAT トラバーサルを実装します。

• WebRTC クライアント間でピアツーピアのメディア伝送を行うことができます。

WebRTC のコア コンポーネント

• オーディオおよびビデオ エンジン: OPUS、VP8/VP9、H264

• トランスポート層プロトコル: 基礎となるトランスポート プロトコルは UDP です

• メディア プロトコル: SRTP/SRTCP

• データプロトコル: DTLS/SCTP

• P2P イントラネット浸透: STUN / TURN / ICE / Trickle ICE

• シグナリングと SDP ネゴシエーション: HTTP / WebSocket / SIP、オファー アンサー モデル

次の図は、WebRTC の内部構造を簡略化した図です。

• 最下層はハードウェア デバイスです。

• 上記は、オーディオ キャプチャ モジュールとビデオ キャプチャ モジュールです。

 

• 中央の部分は、オーディオおよびビデオ エンジンです。

  • オーディオ エンジンは、オーディオの取得と送信を担当し、ノイズ リダクションやエコー キャンセルなどの機能を備えています。

  • ビデオ エンジンは、ネットワーク ジッターの最適化とインターネット伝送コーデックの最適化を担当します。

オーディオおよびビデオ エンジンの上には一連の C++ API があり、C++ API の上にはブラウザに提供される Javascript API があります。

[学習アドレス]: FFmpeg/WebRTC/RTMP/NDK/Android オーディオおよびビデオ ストリーミング メディアの高度な開発
[記事の特典]: より多くのオーディオおよびビデオ学習教材パッケージ、Dachang インタビューの質問、テクニカル ビデオ、および学習ロードマップを無料で受け取ります ( C/C++、Linux、FFmpeg webRTC rtmp hls rtsp ffplay srs など) 必要な場合は、1079654574をクリックしてグループに参加して受け取ることができます~

  

JSEP

• JSEP (JavaScript セッション確立プロトコル、JavaScript セッション確立プロトコル) は、開発者がより強力なアプリケーションを構築し、シグナリング プロトコルの選択の柔軟性を高めることを可能にするシグナリング API です。

• JSEP は何をしますか? 一方では、Web アプリケーションが SDP を生成するために呼び出す createOffer() などのインターフェースを提供し、他方では ICE 関数インターフェースを提供します。これらの機能はブラウザによって実装されており、ブラウザの WebRTC 送信シグナリング (オファー/アンサー) は Websocket を使用します。

  • セッションを確立するための鍵は、メディア ネゴシエーションです. WebRTC は特定のシグナリング プロトコルを指定しませんが、メディア ネゴシエーションは SDP プロトコルを使用します。

  • Web アプリケーションが追加のシグナリング プロトコルを使用せず、JSEP のみを使用する場合、アプリケーションが渡された WS を解析できる限り、2 つの WebRTC クライアント (同じ WebRTC クライアント プログラム、2 つのログイン) 間でリンクを確立することもできます。以上 オファー/アンサー メッセージから SDP および ICE 情報を抽出するだけです。

• github の codelabdemo は、JSEP を使用して、他のシグナリング プロトコルを使用せずにオファー/アンサー シグナリングを直接生成し、送信に ws プロトコルを使用します。

• JSEP はシグナリング プロトコルではなく、SIP などのシグナリング プロトコルを JSEP に基づいて導入して、WebRTC アプリケーション機能をより完全にすることができます。

シグナリング サーバー

• シグナリング サーバーは、主に 2 人のユーザー間で情報を交換するために使用されます。WebRTC はピアツーピア通信ですが、接続を開始して何らかの情報を渡すにはサーバーが必要です。

WebRTC はチャネル確立のためのシグナリング プロトコルを定義していないため、WebSocket、XMPP、SIP、AJAX などの任意のトランスポートを使用できます。

• WebSocket などのリアルタイム転送プロトコルを使用してデータを交換したり、単純な GET/POST メソッドを使用してサーバーをポーリングしてデータを取得したりできます。

シグナリング サーバーによって送信されるデータは、

1. メディアの機能と設定をネゴシエートする

2. セッション参加者の識別と認証

3. メディア セッションの制御、進行状況の表示、セッションの変更、およびセッションの終了

最初の必須機能のみが含まれています。その他は、ビジネス ニーズに応じて自由に調整できます。

SDP プロトコル

• メディア ネゴシエーションの最も重要な機能は、ポイントツーポイント通信に参加している 2 つのブラウザー間でセッション記述プロトコル (SDP) を交換することです。

• 「SDP」には、メディア タイプ (オーディオ、ビデオ、データ)、必要なコーデック、コーデック パラメータまたは設定、帯域幅に関する情報など、ブラウザの RTP メディア スタックを構成するために必要なすべての情報が含まれています。

さらに、シグナリング チャネルは、ICE ホール パンチングの候補アドレスを交換するためにも使用されます。

シグナリング インターワーキング ソリューション

WebRTC と SIP 間のインターワーキング

WebRTC と SIP を相互運用可能にするには、シグナリング層とメディア層の 2 つのレベルの問題を解決する必要があります。

2 つのネットワークで使用されるシグナリング メカニズムは異なるため、メディア ネゴシエーションを完了してセッションを確立するには、シグナリング変換が必要です。メディア層は、コード変換、RTP/SRTP 変換、およびその他の機能を完了する必要があります。

ここでは、主に信号レベルでの相互通信について説明します。

現在、SIP と WebRTC シグナリング間のインターワーキングには 2 つのソリューションがあります。

• JavaScript は SIP プロトコル スタックを実装し、WebRTC アプリケーションはこのプロトコル スタックに基づいて開発されます。WebRTC Client が送信するシグナリングは SIP シグナリングですが、シグナリングの伝送プロトコルとして一般的には websocket が使用されます。

  • このように、WebRTC クライアントは、WS をサポートする SIP サーバーに直接登録できます。jssip と sipml5 の両方がそのようなソリューションです。

• プロトコルの変換は、変換ゲートウェイを介して実現され、相互に通信します。オープン ソース ゲートウェイ プロジェクトは WebRTC2SIP です。

  • WebRTC2SIPは、シグナリング層とメディア層の両方を実装する完全な機能を備えたゲートウェイであり、強力なエンコード変換機能を備えており、両端でメディアを通信するためのエンコードとデコードのメディアゲートウェイとして直接使用することもできます.

ICE サーバー

• ポイント ツー ポイント通信の鍵は、2 つのブラウザーがデータ パケットを直接送受信できることですが、一般的に、ブラウザーまたは携帯電話はルーターを介してインターネットにアクセスするため、ネットワーク アドレス変換 (NAT) が存在します。

• NAT 内の IP アドレスはプライベート アドレスであり、外部からアクセスすることはできません。NAT に割り当てられる IP アドレスはパブリック アドレスです。NAT は、内部から外部にパケットを転送するたびにパブリック アドレスを使用します。

• Interactively Establish Connections (ICE) は、STUN および TURN サーバーを使用して接続を確立する標準トラバーサル プロトコルです。

• STUN サーバーは、NAT をトラバースして、外部 NAT のプライベート アドレスとパブリック IP アドレスを含むブラウザの候補アドレスを取得できます。

• 通信信号チャネルは候補アドレスを交換できます. ブラウザは候補アドレスを送受信すると, 接続のチェックを開始します. チェックが成功すると, 候補を使用してメディアを送信します.

• ほとんどの場合、トラバーサルによって直接のピアツーピア接続を確立できます。ただし、NAT またはファイアウォールの制限が厳しすぎて接続を確立できない場合、メディアは TURN サーバー経由でしかリレーできません。

メディアサーバー

メディア サーバーは必須ではありませんが、マルチパーティ セッションの場合、または追加のメディア処理が必要な場合に考慮することができます。複数のブラウザを使用する会議では、集中型のメディア サーバーを使用できます。この場合、米国のブラウザは、メディア サーバーへの単一の接続を確立するだけで済みます. この構造の利点は、非常に大きなセッションをスケーリングできると同時に、新しい参加者がセッションに参加したときのイベントの数を最小限に抑えることができることです. . 米国のブラウザで必要な処理労力。同時に、メディア サーバーはメディアを分析、処理、および保存することもできます。

JavaScript インターフェイス

getUserMedia

navigator.getUserMedia() を呼び出すことでビデオまたはオーディオ データを取得でき、constraints パラメータでビデオとオーディオのどちらを取得するかを選択できます。ここに簡単な例があります

var constraints = {
  audio: false,
  video: true
};
var video = document.querySelector('video');
​
function successCallback(stream) {
​
  if (window.URL) {
    video.src = window.URL.createObjectURL(stream);
  } else {
    video.src = stream;
  }
}
​
function errorCallback(error) {
  console.log('navigator.getUserMedia error: ', error);
}
​
​
navigator.getUserMedia(constraints, successCallback, errorCallback);

RTCPeer接続

RTCPeerConnection は WebRTC で最も重要なインターフェイスであり、ICE サーバーを決定し、SDP を交換するために使用されます。接続プロセスは次のとおりです。

RTCPeerConnection オブジェクトを作成する

1. RTCPeerConnection のパラメータは、ICE サーバーを決定するために使用されます。以下は、Google によって開かれた STUN サーバーです。

let iceServer = {
    "iceServers": [{
        "url": "stun:stun.l.google.com:19302"
    }]
};
let pc = new RTCPeerConnection(servers);

    2. メディア ストリームを RTCPeerConnection オブジェクトに入れる

pc.addStream(localStream);

オファーとアンサーを介して SDP 記述子を交換する

1. A と B がそれぞれ PC インスタンスを作成する

   • A は、PC によって提供される createOffer() メソッドを通じて、A の SDP 記述子を含むオファー シグナルを作成します。

   • A は、PC が提供する setLocalDescription() メソッドを渡し、A の SDP 記述子を A の PC インスタンスに渡します。

2. A は、サーバーを介してオファー シグナリングを B に送信します。

   • B は、A のオファー シグナリングに含まれる SDP 記述子を抽出し、PC によって提供される setRemoteDescription() メソッドを介して B の PC インスタンスに渡します。

   • B は、PC によって提供される createAnswer() メソッドを使用して、B を含む SDP 記述子応答シグナリングを作成します。

   • B は、PC によって提供される setLocalDescription() メソッドを渡して、B の SDP 記述子を B の PC インスタンスに渡します。

3. B は、サーバーを介して応答信号を A に送信します。

B の応答シグナリングを受信した後、A は B の SDP 記述子を抽出し、setRemoteDescripttion() メソッドを呼び出して、それを A 自身の PC インスタンスに渡します。

アイスホール

1. ネットワーク候補が出たら、シグナリングサーバー経由で相手のブラウザに送信

pc.onicecandidate = function(event) {
  if (event.candidate) {
    sendToServer(event.candidate)
  }
};

2. 相手のネットワーク候補を受け入れる場合は追加する

let candidate = new RTCIceCandidate(candidate);
pc.addIceCandidate(candidate);

3. 相手から送信されたメディアが利用可能かどうかを監視し、メディアを再生します

pc.onaddstream = event => {
  remoteVideo.src = window.URL.createObjectURL(event.stream);
}

RTCDataChannel

RTCDataChannel は RTCPeerConnectionAPI の一部であり、データ チャネルは RTCPeerConnection インスタンスの作成後にのみ作成できます。

データ チャネルを使用して、テキストまたはファイルを送信できます。

pc = new RTCPeerConnection();
dc =  pc.createDataChannel('dc');
dc.onmessage = event => console.log(event.data);
dc.send('text');
dc.sed(new arraybuffer(32))

もう一方の端では、ondatachannel を使用して RTCDataChannel オブジェクトを取得できます。

pc.ondatachannel = event => dc = event.channel;