この記事では、 Webプロジェクトの音声通信を実装する方法について説明します 。
この記事は概要を説明するものであり、幅広い読者を対象としています。 しかし、誰もが問題の本質を深めるために必要なすべてのリンクを見つけるでしょう。
次のタスクが考慮されます。
- サイトユーザー間の一対一の音声通信。
- 音声会議、つまり、2人以上の対話者の会話。
- ブラウザから固定電話と携帯電話への呼び出し。
はじめに
まず、どのテクノロジーが自由に使えるかを理解する価値があります。 現実的には、本質的に唯一のオプションはFlashを使用することです。 はい、他の技術もありますが、残念ながら、それらはすべてあまり一般的ではありません。 Flashはほぼ全員にインストールされます 。
Flashの良いところは、ストリーミングオーディオビデオで作業できることです。 Flashアプリケーションでオーディオストリームを操作するには、主に2つの方法があります。
- メディアサーバー（メディアストリーミングサーバー）を使用する。 この場合、すべての音声トラフィックはサーバーを通過します。 サーバーは、 Flash Media ServerまたはRed5 （オープンソース）にすることができます。
利点：良好なトラフィックフロー（ファイアウォールとNATは障害になりません）。
欠点：サーバーの負荷、長い応答時間、TCPプロトコルのみを使用する機能。
- Flash Player 10に実装された新しいP2M RTMFPプロトコル。
利点： UDPプロトコル、優れた通信品質、サーバー負荷なしに基づいて構築されています。
短所：ファイアウォールとNATを介した不十分な通過性（ユーザーの約60％）には、Flash Player 10バージョンが必要です。
また、近い将来、Flashサーバーがクライアントアプリケーションとの通信にUDPプロトコルを使用できるようになることを期待しています。 この場合、最初のソリューションの欠点の多くはなくなります。 TCPプロトコルはデータの配信を保証しますが、UDPは保証しません。 音声トラフィックをリアルタイムで送信するには、データの正確性は必要ありません。保証された配信時間と定期的な送信チャネル障害に対する耐性が必要です。 これが、この場合にUDPが優先される理由です。
より具体的なことに移りましょう。
一対一の音声通信
開発者の観点から見ると、オーディオ送信を実装するための2つのオプション（サーバーを経由するリレーと経由しないリレー）はそれほど違いはありません。 どちらの場合も、外部サーバーが必要です。 ただし、P2Pの場合、サーバーは接続の確立においてサポートする役割のみを実行します。 すべての音声トラフィックは、クライアントからクライアントに直接送られます。 P2P接続を確立するためのサーバーはStratusと呼ばれます。 間もなく、その機能はFlash Media Server（および明らかにRed5）に組み込まれる予定です。 現在、唯一のオプションは、アドビのパブリックベータサービスを使用することです。
新しいP2Pプロトコルの使用に関するすばらしい記事はこちらです。
実装例はこちらです。
リレーサーバーを使用する場合、タスクはFlash環境の標準です。 この場合、P2Pの場合の主な考え方は、各対話者が発信オーディオストリームを発行し、着信オーディオストリームをサブスクライブすることです。 データは、 RTMPプロトコル（P2Pの場合はRTMFP）を使用して送信されます。
1対1の音声通信の実装における重要な問題の1つは、着信コールに関するユーザーのアラームです。 ユーザーが通話の開始者である場合、ユーザーは音声トラフィックの送信と受信をどの時点で開始するかを知っています。 発信者については、これを通知するために何らかの方法が必要です。 この問題を解決する方法は、特定のアプリケーションの問題です。
- オプション1.定期的に実行される非同期リクエストを使用します。 たとえば、1秒に1回。 リクエストへの応答には、着信コールがあり、それに応答するかどうかを決定する必要があるという兆候が含まれている必要があります。 次に、着信および発信オーディオストリームを構成します。
- オプション2.クライアントがサーバーへの常時接続を維持し、何らかのイベントが発生した場合にのみ応答を受信するComet-architecture 。 この場合、着信コール。
1対1の音声通信の場合、上記の最適と呼ばれるスキームを実装するのは非常に簡単です。 つまり、可能な場合はP2Pを使用し、それ以外の場合はメディアサーバーを使用します。
会議組織
会議を開催するとき、実際には何も変わりません。 すべての会議参加者が一度にすべてのユーザーのオーディオストリームにサブスクライブするようになりました。
繰り返しますが、サーバーとP2Pの両方を使用して実装できます。 ただし、この場合、P2Pが機能しない可能性は、交換に2人の参加者がもはや存在しないという単純な理由により高くなりますが、それ以上は誰にも機能しません。
固定電話と携帯電話への呼び出し
おそらく、検討された人々の中で最も興味深いトピックです。 この問題を解決するために、IPテレフォニーオペレーターのSIPゲートウェイが使用されます。 作業のスキームは次のとおりです。
- RTMPプロトコルを介したFlashクライアントとメディアサーバー間の双方向オーディオデータ伝送が編成されます。
- メディアサーバー側では、音声トラフィックのトランスコーディングが発生します。 つまり、あるコーデックから別のコーデックにオーディオをトランスコードします。 Flashは、 NellymoserとSPEEXの 2つの音声コーデックをサポートしています（バージョン10以降）。
また、メディアサーバーはSIPプロトコルスタックで動作できる必要があります。 - したがって、メディアサーバー側では、Flash Player <-> SIPというブリッジが構築されます。
実施例
P2Pプロトコルを使用したユーザーの1対1の音声通信は、ソーシャルネットワークVKontakte。Onlineのアプリケーションに実装されています。
また、アプリケーションからSIPゲートウェイを介して固定電話と携帯電話に電話をかけるための技術プラットフォームが実装されました。 ただし、この技術は一般公開されませんでした。
Flash <-> SIPバンドルの実装例： flaphone project 。
用途
説明されているテクノロジーには多くの用途があります。 たとえば、エンジン内でCMSシステムを使用したり、会社のWebサイトであるオンラインストアで電話サポートサービスを編成したりします。