私は現在、イントラネット上で通信するために DirectSound を使用するアプリケーションを開発しています。UDP を使用した実用的なソリューションがありましたが、上司から、何らかの理由で TCP/IP を使用したいと言われました。UDP とほぼ同じ方法で実装しようとしましたが、ほとんど成功しませんでした。私が得るのは基本的にただのノイズです。20%は録音された音で残りはただの変なノイズです。
その理由は、TCP が、再生できる最終的なサウンドを取得するまで、受け入れられたすべてのデータを数回読み取る必要があるためだと思います。
今2つの質問：
いいえ、TCP を使用するのはひどい考えです。この場合、UDP はパフォーマンスが大幅に向上し、ドロップされたパケットや非同期パケットは問題になりません。
上司が技術的な詳細を理解できない場合は、現在存在するほぼすべての VOIP システムが UDP を使用しており、Skype、ventrilo、teamspeak、World of Warcraft などの理由があるに違いないことを上司に伝えてください。
この質問に正しく答えるには、VoIP の重要な概念のいくつかを説明する必要があると思います。
まず、UDP はVoIPで最も一般的で広く使用されている方法です。IP ネットワークはパケット交換であり、非リアルタイム データ通信に最適であり、リアルタイム VoIP 用には設計されていないことに注意してください。
この問題を解決するために、UDP が使用されます。UDP は信頼性が低く、コネクションレス プロトコルです。UDP はパケットを失いますが、スピーチの音声は理解できますが、脳はエラーを効果的に補正します。そのため、信号の 3 本のバーでも電話で誰かと話すことができます。
パケット損失とバースト長
パケットロスは輻輳が原因で発生することが多いため、パケットロスの量はネットワークの設備状況によって異なります。UDP を使用した VoIP でのパケット損失は、ほとんどの場合、バースト長で発生します。バースト長は、送信中に連続して失われたパケットの数であるため、バースト長が 3 の場合は、連続して 3 つのパケットが失われたことを意味します。
パケットロス補償
パケット損失が発生した場合、単純なパケット損失補償技術が表面化し、サービスの品質に重大な影響が及ぶことはありません。パケットの 20 ～ 30% が失われた場合でも、音声は理解できます。方法は次のとおりです。
最後に正常に受信されたパケットを繰り返します。
Fill in - ギャップに沈黙を再生します。
スプライシング - 事実上、これはギャップの始点と終点を一緒に押すことによって、バーストの長さによって生じるギャップを取り除くことと考えることができます。
バースト長のサイズを縮小する優れた方法はインターリービングとして知られているため、QoS を向上させる方法はインターリービングです。ブロック インターリーブ機能は、音声を受け取り、それを一連のパケットに分割します。これらのパケットは、行列の形状 (例: 4 x 4) のバッファーにロードされます。関数を使用してバッファーを回転または転置し、パケットが順序どおりにならないようにします。受信者側では、この関数の逆を使用してパケットを並べ替えます。この方法は簡単で効果的です。下の図を参照してください。
代替テキスト http://img688.imageshack.us/img688/3962/capturevnk.png
最近、小さな VoIP アプリを作成しました。UDPを使用した無線LAN経由。アプリケーションの正確な要件についてはよくわかりませんが、一般に、(2 つのホスト間の) VoIP アプリケーションは次のように実装できます。
代替テキスト http://img338.imageshack.us/img338/6566/captureec.png
図では、アプリケーションが独自のパケット設計を定義しています。ヘッダーはパケット番号 (1 バイトを使用) であり、ペイロードは音声データ (n バイト、ペイロードのサイズ) です。これを定義すると、より優れたパケット補正技術が可能になり、プログラミングの論理フローが可能になります。
TCP は、いくつかの理由から VoIP には適していません。「TCP VoIP」をグーグルで検索すると、最初の結果がこの見解を支持する理由が明らかになります。
TCP は信頼性の高い接続指向のプロトコルです。これは、送信中に失われたパケットがある時点で他のホストから再送信されることを意味します。この再送信は、リアルタイム サービスには実用的ではなく、ジッターや遅延が増加し、場合によってはパケット損失が増加する可能性があります。
ご質問への回答
私が得るのは基本的にただのノイズです。20%は録音された音で残りはただの変なノイズです。
TCP はノイズを導入してはならず、ジッタとレイテンシを導入する必要があります。ソケットにはタイムアウト時間が自動的に定義される傾向がありますが、タイムアウト時間を定義していますか? そうでない場合、再生前に正しいパケットを受信できないのはなぜですか?
私は正しい軌道に乗っていますか？この種のアプリケーション (ある種の音声会議) に TCP/IP を使用することは良い考えでしょうか?
いいえ、TCP/IP を使用しないでください。これは良い考えではありません。あなたのマネージャーは、パケット損失がひどいものであると誤って想定しているようです.
概要
ここでは、この特定の問題に対して可能な限り役立つように、いくつかの一般的な重要な概念を示していますが、これですべてを網羅していると見なすべきではありません。VoIP システムが音声コーディング/信号処理技術の基本原則を使用していることを確認してください。
覚えておくべき重要なポイントは次のとおりです。
VoIP には UDP を使用します。
パケット損失補償
技術を実装します。
ブロック インターリーバーは、
QoS を向上させるための簡単で効果的な方法です。
これが役立つことを願っています。
人々が TCP/IP スタックについて話すとき、UDP を含む「インターネット プロトコル スタック全体」を意味することがよくあります。多分それはあなたのマネージャーを幸せにします;-)
最新のルーターとネットワーク上の TCP/IP は非常に高速です。Voice over IP 通信を処理する以上の能力を備えています。(自分でやりました)
私の推測では、実装にはバッファ サイズに関連するいくつかのバグがあると思います。
TCP/IP は機能します。データを配信します。パケット損失を気にしていなければ、UDP ほど効率的ではないかもしれませんが、データを問題なく送信できるはずです。
私は、アマチュア無線トランシーバーのリモート コントロール用に、wave-api との二重通信用の音声操作 IP ソリューションを開発しました。UDP や TCI/IP でも非常にうまく機能します。64ミリ秒ごとに512バイトのバッファを使用し、8kHzのモノウェーブデータを使用しています。先月、TCP/IP を介してアメリカとヨーロッパの間で仕事をしました。ここで私の質問: Wave-API は Win7 では正しく動作しないため、DirectSound の方が良い方法だと思います。私のアプリケーションは VB.Net 2008 です。DirectSound - ManagedDirectX9 for VB.Net を使用したストリーミング出力のドキュメントへのリンクを検索します。
TCP 経由でノイズが発生する理由はなく、コードのバグのように見えます。実際、私たちが受信するほとんどのストリーミング メディア (YouTube など) は、TCP 経由で行われます。
TCP の問題はジッターです。すべてのパケットが受信され、並べ替えられるまで、データ ストリームの配信は遅れます。現在、マルチメディアの配信が遅れていることは、まったく配信されていないことと同じです。これは通常、欠落しているフレームを単純に補間するよりも適切な選択ではありません。前述のように、パケット損失が最小限であり、ネットワークが高速である場合、違いはありません。
RTP/RTCP over UDP は通常、メディア ストリームの配信に使用されます。RTP には、可能であれば、遅延パケットを正しい位置に挿入できるように、パケット ヘッダーにシーケンス番号のようなものが含まれます。RTCP には、コーデックがパケット損失が高くなり始める状況に適応できるようにするレポート機能があります。したがって、RTP/RTCP は一部の TCP 機能を提供しますが、すべての TCP 機能を提供するわけではありません。
TCP 経由でメディアをストリーミングする場合、これは大きなジッター バッファーを持つことで簡単に解決できます。これによりレイテンシが追加されますが、一方向ストリーミングの場合、これは問題になりません。ただし、双方向の会話型ストリーミングではレイテンシが大きな問題になります。
ただし、TCP の主な利点の 1 つは、UDP よりも簡単にファイアウォールを通過できることです。TCP セッションが確立されると、データの送信と受信の両方に対してファイアウォールが開かれます。これは、特にデータの着信ストリームが予想される場合、UDP の場合はより複雑になります。これを回避する方法はありますが、複雑になる可能性があり、セッション制御プロトコル (SIP や RTSP など) の理解が必要になる場合があります。
ほとんどの音声アプリケーションは、UDP ポートを介したストリームである RTP プロトコルを使用して構築されています。それらのほとんどはコーデックをサポートしており、一方の端からもう一方の端にストリームする前にメディアが圧縮されるようにします。帯域幅の要件について上司と話し合ってください。
ライブ ストリーミング データが UDP を使用する主な理由はいくつかあります。遅延データの最大の原因は、データをまったく受信しないのと同じくらい良いことであり、再送信のためにストリームを遅らせることは、確かに良い考えではありません。VoIP の場合、約 150 ミリ秒の遅延許容範囲があります。それよりも長く遅延した音声パケットは、ユーザーにとって目立ちます。
ノイズが発生する理由については、再送信による遅延到着パケットをどのように処理していますか?
ノイズが発生している場合は、パケットで正常に満たされたバッファの一部をオーバーランし、空の/初期化されていないバッファを再生している可能性があります。
TCP は UDP よりどれくらい遅いですか? TCP を使用すると、パケットが順不同で到着したり破損したりした場合、再送信の遅延が発生します。遅延が少なくなるように TCP を最適化する方法があると思います。Linux と Winsock の両方で、使用する TCP_NODELAY オプションがあります。また、コンパクトなコーデックは、G.729 のようにペイロード サイズを抑えるのに役立ちます。送信は受信されるパケットに基づいているため (TCP の順序で)、パケット サイズを最適化して、再送信の遅延を減らすのに十分小さく、ストリームの品質を維持するのに十分な大きさにすることに重点を置く必要があります。優れた TCP voip プログラムには、エンコーディングの品質とパケット サイズをオンザフライで変更する機能があり、送信者は変更を受信者に通知する必要があります。しかし、リアルタイムに TCP を使用する唯一の利点は、ファイアウォールによってブロックされる可能性が低いことです。
基盤となるネットワークの種類にもよりますが、信頼性が 99.9% のイーサネットを使用している場合、TCP で問題ないと思います。ただし、たとえば 802.11 で実行している場合、TCP はあまりお勧めできません。
TCP を使用する特定の理由を上司に尋ねてから、その特定のサービス (基本的な信頼性や UDP を介したエラー修正サービスなど) を実装できます。RTP も調べてみてください。( http://en.wikipedia.org/wiki/Real-time_Transport_Protocol )
TCP がノイズを発生させてはなりません。ジッターとラグ、はい (特にリンクに損失がある場合)。しかし、ノイズはまったくありません。あなたのプログラミングには何か怪しいものがあります。
ところで、この場合、UDP が TCP よりもはるかに適切であることに同意します。
ほとんどのストリーミング オーディオ/ビデオは UDP を使用していると確信しています...いくつかのパケットが失われる可能性がありますが、決して気付かないでしょう。
