ブラウザーからWebRTC呼び出しを開発するときの5つの間違い

WebRTCは最も簡単なものではありません。 APIがすべての主要なブラウザをサポートするようになったのはごく最近ですが、注意と「ニュアンス」があります。 これに加えて、SIPの突出した形のVoIPテレフォニーの暗い遺産、oRTCを使用したハリネズミとSIPの間の闘争、失敗した星の組み合わせで落ちるブラウザ-そして、あなたは夕方にはコワーキングで燃えないものを手に入れます。 Tsakhiは、bloggeek.meの常連の著者であり、かつてのテレコム開発者でもありますが、大丈夫です。 また、Voximplantでは、ブラウザを使用した音声通話とビデオ通話の長年の経験に基づいて、Habrの翻訳を適応させています。

WebRTCでできないのはなぜですか？

開発者およびコンサルタントとして、私はWebRTCで成功しなかった才能あるプログラマーをたくさん見ました。 彼らは新参者に典型的な間違いを犯しましたが、これは私のアパートの洪水時に私が犯したいタイプのエラーではありません。 WebRTCを使用する才能のある開発者は、他のテクノロジーを使用するよりもはるかに頻繁に失敗します。 マーク・トウェインの有名な引用：

新しいアイデアのようなものはありません。 これは不可能です。 たくさんの古いアイデアを取り、それらを精神的な万華鏡に入れます。 私たちはそれを回転させ、アイデアが新しい面白い組み合わせを生み出します。 回転を続け、新しい組み合わせを無限に作成します。 しかし、これらはすべて私たちが何世紀にもわたって使用してきた色ガラスと同じものです。

この声明は、WebRTCでの多くの子供時代の間違いの根源に関するものです。 このテクノロジーは、マーク・トウェインの万華鏡のパターンと同じように「新しい」ものです。 たくさんの古いアイデアと新鮮で面白い組み合わせが混ざり合っています。 私たちはこれを知っており、私たちはそのようなものを扱うことができると信じています。



ビジネスマン？ Skypeは14歳です。 最近のSkypeのようなものを作成することはそれほど難しくないはずです。



VoIP開発者 ？ SIPを知っています。 WebRTCは、シグナリングのないSIPに似ています。 そこで、SIPをそこにねじ込むだけで完了です。



Web開発者ですか？ WebRTCはHTML5の一部です。 JavaScriptコードの数行で、リリースの準備がほぼ整いました。



ビデオサービスの開発者ですか？ WebRTCビデオストリームを取得してCDNに配置することはできますか？



結果？

1. 優れた開発者は、助けなしですべてを行うのに十分な知識があると信じています。 すべてが非常に興味深いエラーで終わります。
2. これらの分野の専門家を信じています。 すべて失敗に終わります。

私は最近、2018年にWebRTCアプリケーションにPeerJSライブラリを使用することを決定したチームに夢中になりました。 PeerJSは、しばらくの間、2015年に最後に更新された402行のJavaScriptコードです（！）。 そのような古いコードは、単にWebRTCを操作するために使用することはできません！ 1年以上前のコードは、すでに無効になっているか、またはシュガーされています。 WebRTCは未だに新しく、変化が早すぎます。



ところで、私たちにはあまり選択肢がありません。 Flashは死にかけています。WebRTCに代わる深刻な代替手段はありません。 プロジェクトでWebRTCを使用する場合、避けるべき5つのよくある間違いを以下に示します。

間違いその1：誤ってチューニングされたSTUN / TURN

開発者がNATをバイパスするようにサーバーを構成できない頻度は信じられません。 昨日、誰かが私のサイトのチャットウィジェットを通じて、STUN / TURNサーバーを使用せずにHostGatorを使用してアプリケーションとアラームを展開する方法を尋ねました。



簡単な答え：方法はありません。 いくつかの難解な場合を除き、STUNサーバーが必要になります。 また、セッションを相互に接続する場合、ほとんどの実用的なアプリケーションにはTURNサーバーもあります。 先月だけ、次のNATトラバーサルについて話しました。

• STUNサーバーとTURNサーバーの両方を使用する必要があります。
• 無料のSTUNサーバー（たとえば、よく知られている "stun.l.google.com:19302"）や"無料" TURNサーバーに依存することは避けてください。
• 必要な理由が完全にわからない限り、TURNを介してすべてのセッションを送信しないでください。
• TURNを使用しても、接続に対する追加の保護は提供されません。
• WebRTCに複数のSTUNと3つのTURNサーバー（UDP、TCP、およびTLS）を送信する必要はありません。
• TURNを構成するには、TURN設定で一時パスワードまたは一時パスワードを使用します。
• STUNサーバーは、音声とビデオの品質には影響しません。
• cotunまたはrestundは、STUN / TURNサーバーに適しています。

これだけではありませんが、最初から十分です。

間違いその2：シグナリングの間違ったフレームワークを選択する

PeerJS？ 典型的な「観光客のtrap」のように見えます。









このプロジェクトには1,693個の星と499個のフォークがあり、WebRTCに関連する最も人気のあるgithubリポジトリの1つです。 何がおかしいのでしょうか？



おそらく、プロジェクトはインターネットよりも少し古くなっていますか？









3年以上前に最後にコミットされたWebRTCに関連するプロジェクトは、2018年には使用できません。 同じことがMuaz Khanのコード例にも当てはまります-それらが商用レベルであり、安定していてスケーラブルであることを期待すべきではありません。 いや 便利なコード例。



他のオープンソースプロジェクトを使用する予定ですか？ 以下を確認してください：

• このプロジェクトは、ここ数か月で更新されました。
• 彼は非常に人気があります。
• プロジェクトコードを理解し、必要に応じてプロジェクトコードを変更できます。
• （有料）ヘルプが必要な場合は、鉱夫に連絡できます。

シグナリングとデータ転送用のサーバーの選択について真剣に考えてください。

間違い3：必要なときにメディアサーバーを使用しない

WebRTCを使用している開発者が何を考えているか知っています。 このテクノロジーはピアツーピアであるため、サーバーは必要ありません。 一部の人は、シグナリングとWebサーバーがなくてもできると信じています。 参加者のブラウザがピアツーピアコールを行うためにお互いを見つける方法を説明できることを願っています。



多くの場合、ピアツーピアの概念は、メディアを転送するためのサーバーなしで、多数の参加者とのセッションを作成できることも意味します。 そのような「アーキテクチャ」の例が2つあります。









真空中の球状メッシュ。 かっこいい。 しかし、今年または来年に、そのようなものを機能させることが可能になるとは思わないでください。 次に進みます：









転送を使用したリアルタイムブロードキャスト。 これを行うことはできますが、結果は、遅延なしの数百万人の参加者の予想されるスケーラビリティからはほど遠いでしょう。



実際には、メディアデータ（音声とビデオ）を送信するメディアサーバーが必要です。 これがわかったので、 オープンソースまたは商用ソリューションを検索できます。

間違い4：戦略のない戦術

優れたアウトソーシング業者を見つけ、製品要件を満たし、有効なソリューションを支払いました。 背後に問題はありますか？



いや



WebRTCテクノロジー自体はまだ非常に若いです。 公式の仕様は変更されています。 ブラウザでの実装は変化しています。 これはすべて一定の動きです。 WebRTCを使用する場合は、次の2つのオプションのいずれかで停止することをお勧めします。

1. 既製のプラットフォーム（ ここにいくつかありますが 、Voximplantがあります）を使用し、開発コストの一部と毎月の支払いのサポートを交換します。
2. 独自のソリューションを開発します（または開発を外部委託します）。 この場合、3年以上プロジェクトのサポートに投資する必要があります。

WebRTCコードは、他のどのHTML5コードよりも速く腐敗します。 いつかそれは止まりますが、明らかに今ではありません。 このため、数年前に同僚と一緒にtestRTCを作成しました。WebRTCを使用して、特にテストと監視の観点からソリューションの開発を支援するためです。

間違い5：WebRTCの仕組みの誤解

彼らは仮定がすべてのエラーの原因であると言います。 Googleはこれに同意しているようです。 のようです。



WebRTCは、VoIPとWebの交差点のどこかにある最も些細な技術ではありません。 それは新しく、それに関する多くの情報がありません。 そして、存在するものは非常に頻繁に変更されます（結論：この情報のほとんどはすでに古くなっています）。



WebRTCを使用する場合は、テクノロジーとその範囲を必ず理解してください。 展開するサーバー。 WebRTCがシグナリングと対話する方法（シグナリングとは、ネットワーク上に誰がいて、どのメディアデータを転送すべきかを理解するために、ブラウザまたは他のWebRTCデバイス間でデータを交換することです）。 ネットワークメディアを介したデータの処理および送信方法：音声、ビデオ、および「ユーザー」。 WebRTCを使用するための既成のソリューションは何ですか。



学ぶべき多くの異なるもの。 Web、VoIP、またはビデオ技術の知識に頼らないでください。 WebRTCはあなたを驚かせるでしょう。