ブラウザーを介したビデオ通話-テクノロジーを会社に役立てる方法

社内のブラウザを介してビデオコールを発信する方法と、その有用性を理解することは非常に興味深いことでした。 さらに、スカイプは「タップ」され、転送されたパスワードはロボットによって解析されます...



Google+ハングアウトがあり、頻繁に使用されているようですが、それでもWebRTCや独自のクラウドテクノロジーではありません。 誰が知っている-他の競合他社の同僚がメモ帳と輝く顔に本物の笑顔で私たちの事業計画会議を見ていますか？



一般に、社内での信頼できるプライベートなビデオ会話のトピックは、これまで以上に関連性があることを認めなければなりません。 多くの人々がそれを必要としますが、何かを整理する方法は？ やった 方法を知っていれば、これは非常に簡単に行えます:-)（RFC、w3cの標準とその実装を十分に研究し、理由を突き止めた後）。



以下では、実装の主な技術的リスクを実行しようとします。これは私たちが踏まなければならなかったし、おそらくあなたを踏まなければならないでしょう-そして、スナックのために：脳を爆発させる不必要な詳細なしで、簡単な技術的圧迫とビジネスTODO。

技術

画期的なHTML5テクノロジーの1つは間違いなくWebRTCであり 、Google、Mozilla、Operaのサポートを受けてw3cによって開発されました 。



その本質は、私のコンピューターにカメラ、マイク、ブラウザーがあり、どこにいてもブラウザー、カメラ、マイクを使って他の人とビデオ通話をすることができることです。隣のテーブルの同僚と、美しいラップトップでビーチで日光浴をしている上司の両方です女性の身体 この場合、接続は暗号化され、1つだけで、ピアツーピア-2の間だけです。 かっこいい？ しかし、それだけではありません。



強力なブラックマジックを使用して行われるアクションは 、ブラウザーの「内部」でほとんど透過的です。ユーザーとプログラマーは、コーデック、ファイアウォール、調整、SIPなどを気にしません。 -最も単純なケースでは、一目でビデオ通話のタスクは十数行のjs-codeによって解決されます。ここでは、幸福です-あなたの会社でプライベートビデオ会話が機能します。





このスキームを掘り下げないでください。さもないと、脳が爆発する可能性があります。 数十年にわたって、開発されたメディアテクノロジーとプロトコルは、テレビスタジオ、ラジオ局、電話交換局などのブラウザ内に閉じ込められてきました。



しかし、ご存知のように、悪魔はささいなことに隠れています。 それらについてお話します...

シグナリング

WebRTCテクノロジーの説明には、ロマンチックなプラグアンドプレイのサクセスストーリーと、 スタン 、 ターン 、 アイス 、 sdpという用語のスイープからのワイルドで低レベルのハードコアという2つの著しく異なるトピックがあります。 skipipastは機能しますが、それがどのように明確であるか、または6か月間ソースコードとRFCを調査しません:-)



私たちを駆り立てる筋金入りの用語の1つはシグナリングです。 実際、3つの簡単なタスクを実行します。



1）2つのブラウザーの構成をドッキングします（オーディオ/ビデオストリーム、コーデック、アドレス、およびポート-SDP形式）





SDP この悪夢はブラウザ間で伝達され、その詳細は回避できます。 しかし、RFCを読んだ後でも、堆積物は残っています



2）パスワードを交換して、ブラウザー間で暗号化された接続を確立します

3）アクションの開始-コール（jsのコールバックでクライアントAスレッドをクライアントBスレッドに接続）、電話を切るなど つまり ブラウザのjsでは、 RTCPeerConnectionオブジェクトを使用して非常に簡単なことを実行していますが、オブジェクト内には実際のADBがあります。



つまり シグナリングを使用して、何でも何でも書き込みます-ブラウザは互いにドッキングし、ビデオ通話を行うことができます。 そして、驚くべきことに、プロトコルスタックの内容を理解することはできません。呼び出しは驚くほど簡単になります。



視覚的に信号を送ることは恐ろしく見えます-実際、ICEを介したブラウザ内のメディアストリームのSDP記述は単に「追跡」されます...ええ、私はただ書きたかった-それは機能しません

ブラウザはお互いを探しています

呼び出しは単にローカルネットワーク上で取得されますが、従業員が別のネットワーク上にある場合、そしてファイアウォールの内側でさえ、ブラウザは何の助けもなしに接続を確立できません。



技術的には、上記のセクションよりもさらにハードコアがあります、すぐに警告しますが、指で言うと次のようになります：

1）会社のファイアウォールを「パンチ」するには、従業員がSTUN / TURNプロトコルを使用して特定の中央サーバーに接続する必要があります。 このサーバーは、システム管理者によって作成されるか、無料で使用できますが、機能が制限されています（TURNリレーモードのサポートはありません）。

2）ファイアウォールを「突破」することができなかった場合、唯一の可能性が残ります。ブラウザ間でピアツーピアではなく、サードパーティのサーバーを介してメディアストリームを注ぐことです。 TURNサーバーのこの動作モードは「リレー」と呼ばれます。 このようなサーバーを自分で理解する必要があります- オープンなソリューションがありますが、WebRTCでそれらを自分で構成する必要があります。 ただし、統計によると、ビデオコールの約10％だけがリレーモードになります。



繰り返しますが、ビデオコールが確実に社内に届くように、「外部の」STUN / TURNサーバーを選択または使用します。





これは、メディアストリームがユーザーブラウザー間を直接または中継サーバーを介して移動する方法です。 はい、これはひどくて見た目が悪いです-しかし、ファイアウォールはまだファイアウォールを「パンチ」するためのより良い方法を考え出していません。 Skypeもこの原則に基づいています。





ICEは氷ではなく、RFCで定められているビデオストリームを交換するための最適なルートを選択するための技術であることを理解しなければ、さらに先へ進むことはできません。 プロトコルスタックSTUN / TURN / ICEの過度の、ugい、非論理的な複雑さによる堆積物のレベル-クリティカルレベルに増加しました。

ビデオ会議

WebRTC-ビデオ会議を直接サポートしません。 ビデオ/オーディオストリームとブラウザがあり、結合します。 Skypeは有料サービスです。 Google+ハングアウト（ちなみにWebRTCは使用しませんが、Chromeプラグインと特定のコーデックで動作します！）-制限は10〜15人です。



難しさを理解していますか？ すべてのビデオストリームはどこかで収集され、特定の参加者用の1つの個人的なビデオストリームに変換され、彼に返される必要があります。 つまり 10人の場合、各個人ビデオストリームから参加者のフレームを取得し、それらをホストのフレームの下のどこかに置き、生成されたフレームを特定の参加者に渡します。 また、WebRTCコーデックと互換性のあるブラウザーをサポートするフレームを収集する必要があります。 計算量を想像してください。 このような「MCUサーバー」のオープンな実装があります。

1） licode-私見未加工であり、正直なMCUではなく、ただストリームを多重化します。

2） MCUビデオミルティコンフェレンスサーバー -ただし、ChromeソースとWebSocketsを介したWebRTCをサポートする最後のアスタリスクからのコピーの直後に起動しませんでした。 そして、どういうわけか怖い-JavaのJavaとJAVスロー:-)





恐ろしいですね、私は同意します。



もちろん、ビデオ会議を開催するための商用製品と業界全体がありますが、この記事ではWebRTCのみに焦点を当てています。



WebRTCでは、もっと簡単なことができます。ビデオ会議では、各ブラウザが各参加者のビデオストリームを保持します。 jsのブラウザ内でこれをプログラムし、シグナリングに関連付ける必要があります。 はい、ここでのトラフィックは増加していますが、社内から複数の人々への電話では、このソリューションはそのシンプルさと効率性に魅了されています。

ブラウザは異なります

Chrome-Chrome間のビデオ通話は安定して動作します。 その他の組み合わせ：Chrome、Firefox、Opera-動作しないか、正式に動作しますが、実際には動作しません。 しかし、それにもかかわらず、彼らは新年からChrome-Firefoxビデオ通話の信頼できる操作を約束します。



哲学的に見ると、すべての企業が特定のバージョンのブラウザーに縛られているわけではありません-そして、おそらく同僚とのコミュニケーションをChromeで行うことができます。

WebRTCとテレフォニー

しかし、真実は、ブラウザから固定電話/携帯電話に、そしてその逆に電話をかけてみませんか？ 可能ですが、...しかし、ここでは、音声とビデオを送信する技術に没頭せずに行うことはできません。 最初の「衝撃」はSIPプロトコルです 。 IPテレフォニーとSIPは複雑な技術ではありませんが、WebRTC標準ではSIPについては言及されていません:-)



そして、すべてがシンプルです-SIPの指で議論-これは一種の強力で柔軟なシグナリングです（上記を参照）。 しかし、自分で信号を書く場合-なぜSIP フォトニックロケットと銀河間宇宙船が必要なのですか？



この不一致により、SIPを理解し、WebRTCを介してブラウザをドッキングできるjsライブラリ （ アセンブリ言語 ）の作成などのモンスターが発生し始めました。 そして、 アスタリスクは、WebRTC経由で通信したいブラウザとの統合のためにWebSocketのサポートを開始しました...しかし、技術同士の明白な不可侵性および技術スタックの複雑さにより、社内のWebRTCコールでのSIPの使用が問題になります...この場合のjs + sipは過剰ですが、可能性はありますが）。





SIPはWebRTCでシグナリングが行うことですが、より深刻なのは、複雑で分散しています。



上記の問題を解決する別の方法はそのような呼び出しを専門とする会社のサービスを使用することです。 詳細に飛び込むことなく、特別なjs-libraryを使用するだけで、会社の特別なWebサービスを通じて固定電話と携帯電話番号に電話をかけることができます。



したがって、ブラウザから電話番号に電話をかけるタスクも解決されます。

まとめると

事実を要約し、機会とリスクを比較検討しましょう。 安全なビデオコールを独立して合理的な時間内に会社に展開できます。 技術はオープンで、説明されている、あなたはジャングルに入ることができない-なぜなら 私はすべてのリスクを客観的に説明し、ハードコアの技術的絞り込みを高めようとしました。



社内でWebRTCを介してビデオ通話を開始するには、次のことが必要です。

1. 会社のビジネスプロセスの詳細を考慮に入れて、ADの従業員のリストにアクセスできる、などのシグナリングを記述します。
2. 会社のローカルネットワークの外部に1-2台のSTUN / TURNサーバーを設置して、さまざまな会社のオフィスやモバイルデバイスからのビデオ通話を接続します。 暗号化されている場合でも、ビデオトラフィックがこれらのサーバーを通過する場合があります
3. 複数の人向けにビデオ会議を開催するための非常に生の製品またはかなり複雑な製品との統合を試みるか、ビデオ会議のWebRTC実装を記述してください
4. 会社との間で通常の電話番号に電話をかける可能性のために「ゲートウェイ」と統合する

技術的には、タスクは解決可能です。 しかし、これらすべてを行う時間がない場合は、たとえば、上記のすべてをサポートする製品またはクラウドサービス （無料の登録と、どこでも通話できるアカウントの100ルーブル-テクノロジーをテストして、必要かどうかを理解できます）を使用できますすぐに使えるビデオ通話技術と、STUN / TURNプロトコルをサポートするビデオサーバーのクラスターを使用します。

テクノロジーオペレーション

実装オプションを選択し、社内のブラウザーからのビデオ通話の使用を開始しました。 どういうわけか沈黙している、または彼らがそれについて知らないという1つのポイントがあります-通り抜けることが不可能なとき、まれなケースが可能です。 これは、ブラウザーがお互いを直接見つけることができず（ICEを介してピアツーピアをインストールする）、最後の機会を使用しようとしているという事実によるものです。外部リレーサーバーを介して接続を確立しますが... 。 ただし、TURNはUDPを介したリレーモードのみをサポートしています（詳細についてはRFCを参照してください）。 それを許可するのに十分-とビデオ通話が再び動作します。



別の一般的な質問は、トラフィックとビデオのサイズです。 TURNサーバーのリレーモードでは、1つの接続が1秒あたり数百キロバイトを消費します。トラフィックは、ブラウザーのビデオのサイズに直接依存します。 つまり リレーモードで高密度のビデオ会議が必要な場合は、事前に検討してください。



おそらく、私が興味深く有用なことを伝えたかったのはこれだけでしょう。 新年、作業中のプロジェクト、従業員の満足をお祈りします！