WebRTCの落とし穴の 1つは特別です。 これは、ブラウザがメディアストリームの転送に同意する方法です。 コーデック、ビットレート、ビデオ解像度-これがすべてです。 メディアストリームコードは1つだけです。すべて問題ありません。 しかし、それらが2つある場合（音声付きのビデオ、2つ目のメディアストリーム：1つはビデオ用、もう1つはサウンド用）、状況記述形式に関するブラウザの意見は大きく分かれています。 FirefoxでChromeからビデオ通話を行うのはとても簡単です。 しかし、音声付きのビデオ通話はもうありません。 カットの下では、なぜそれが起こったのか、新しいSafariでそれを見て、Microsoft Edgeが持っている特別な方法について少し話があります。
音声通話とビデオ通話の分野の収穫機
WebRTCはコンバインハーベスターです。 多くのプロトコルと異なる名前のJavaScript APIが1つの名前の下にあり、異なる動作をします。
- カメラからのビデオおよび/またはマイクからの音声をキャプチャします。
- ブラウザでサポートされている異なるコーデックによるエンコードとデコード。
- ICEアプローチと指定されたサーバーを使用して、ブラウザー間でピアツーピア接続を確立します。 NATを突破できず、外部サーバーを介して接続する必要がある場合、ネットワークトポロジを調査するためのSTUNサーバーとTURNサーバー。
- ネットワーク経由でビデオとオーディオを転送します。 さらに、チャネル幅の分析およびコーデックビットレートの微調整。
- 再生を受け取りました。
- UDPまたはTCPスタイルのデータ転送。
- 画面共有。
この話の最も難しい部分は、ピアツーピア接続を確立することです。 これがタブ間のローカル通信ではない場合、デバイスが同じネットワーク上にない場合、またはポートが開いている実際のIPアドレスがない場合、「ネゴシエート」するためにいくつかの中間サーバーが必要です。 通常、これらのサーバーは、WebRTCを使用したい開発者によって作成されます。 STUNを除き、「私のパブリックIPとは何か」という質問に答えるエコーサーバーは、Googleから公開されています。
開発者が送信しようとしているもの（音声、ビデオ、または任意のデータ）に応じて、ピアツーピア接続が確立されます。 WebRTCは、テキストパッケージ「提供」、「回答」、「氷候補」を作成します。開発者は、これらを互いに接続するブラウザー間で（通常は自分のシグナリングサーバーを介して）送信する必要があります。 これらのパッケージでは、両方のブラウザーがその機能と今後の動作を説明し、WebRTCは最適な接続方法を選択しようとしています。
テレフォニーSDPレガシー
WebRTCが開発者の手と交換するパッケージは、SDP形式を使用します。 それは非常に古く、テキストであり、電話から来ました（WebRTCはブラウザから電話ネットワークへ、またはその逆に呼び出すとき、開発者の努力を最小限に抑えようとします）、HTTPに似ています。 SDPパッケージは次のようになります。「このブラウザーは別のブラウザーへのピアツーピア接続を確立しようとしていますが、ネットワークを介して何を送信するかはまだわかりません。」
開発者がデータ、音声、またはビデオの転送を開始/停止したい場合、WebRTCはすぐに彼からの「再ネゴシエーション」を要求します-送信されたデータのネットワークルートの最適性を確認し、コーデックについてネゴシエートするためにピアツーピア接続を再起動します。 これは、WebRTCがビデオの送信を希望することを告げるSDPパッケージの外観です。
非表示のテキスト
急速に変化する標準
WebRTCは長年にわたって私たちと一緒にいましたが、まだベータ版の状態です。 最近、JavaScript APIはコールバックからプロミスに完全に書き直され、音声およびビデオストリームの動作が変更され、Microsoftは代替API「oRTC」を作成しました。 多くの興味深いことが起こりました。 また、SDPパッケージのメディアストリームを記述する形式が変更されました。 長年、使用されていた階層構造の「プランB」は廃止され、「統合プラン」に置き換えられました。各ストリームは、SDPパッケージの個別のセクションで定義されていました。 比較してください。
それは：
非表示のテキスト
次のようになりました：
非表示のテキスト
Chrome vs Firefox vs Edge vs Safari
Webテクノロジーのベータ版に関しては、ブラウザーでの実装が大きく異なる場合があり、標準の現在のバージョンに何年も遅れることがあります。 そのため、WebRTCで起こりました。 何年も前、Google Chromeは「Plan B」形式のいくつかのメディアトラックをサポートしていましたが、実装を「Unified Plan」に変更していません。 対応するチケットは数年前に開かれ、開発者はこれがどれほど重要かを議論し、チケットを相互に再割り当てしていますが、まだそこにあります。 典型的なFirefoxでは、統合プランのみが実装されているため、問題なく音声または音声なしの1つのメディアトラックのみを通信できます。 もっと必要ですか？ アダプターとポリフィルの世界へようこそ！
最初に独自のoRTC APIの実装のみをサポートするMicrosoft Edgeは、最近のバージョンでWebRTC APIと統合プランのサポートを追加しました。 Safariは、次のバージョンのWebRTCのみをサポートします。ベータ版はすでに開発者が利用できます 。 そして、悲しいことに、プランB。これはChromiumに基づいて作成されたためです。
ブラウザー間の呼び出しを行う方法
ご覧のとおり、最も人気のあるブラウザであるChromeには、古い「Plan B」形式が残っています。 Safariがあり、そのモバイル版はiPhoneにあります。 Firefoxおよび新しい統合プランを備えた新しいMicrosoft Edge。
音声なしで音声またはビデオを転送する場合、これは何の役割も果たしませんが、複数のメディアトラックの場合は、SDPを手動で変更するか、 アダプターを使用する必要があります。 遅かれ早かれ、すべてのブラウザが統合プランに切り替わることを本当に望んでいます。 しかし、現時点では、ほとんどのデスクトップおよびモバイルブラウザーの大部分がプランBをサポートしているという厳しい現実があり、FirefoxおよびEdgeとの互換性のためにコードを追加する必要があります。 そして、多くのデバッグが必要です。
katの前の写真はここから撮影されました。