6

専門家の意見が必要です。私の質問自体が混乱した質問である場合は申し訳ありません。

私はVOIPアプリケーション（クライアント/サーバー）の構造について読んでいました。また、ほとんどの場合、音声ストリームには UDP が推奨されます。また、paltalk や inspeak などのいくつかのボイスチャット アプリケーションを確認したところ、それらのサイトでは、以下の理由で正しくないように思われる udp 音声ストリームを使用していると記載されています。

paltalk と inspeak が使用するトラフィック/ポートを調べました。UDP と TCP のポートが開いていて、パケット スニファを使用すると、UDP 通信があまり行われていないことがわかりますが、ほとんどの場合、TCP 通信が行われています。

また、私の知る限り、UDP プロトコル サーバーでは、NAT (DSL ルーター) の背後にあるクライアントにデータを送信できません。また、「UDP ブロードキャスト」は、「インターネット」ベースのボイス チャット アプリケーションのオプションではありません。そのため、yahoo はドキュメントで、udp 通信が不可能な場合に yahoo メッセンジャーが tcp に切り替わると述べています。

だから私の質問は....

  1. 上記のステートメントで何か間違っていることを理解していますか?

  2. UDP が使用できない場合、それらのチャット アプリケーションは音声に TCP ストリームを使用しますか?

  3. TCP音声ストリームが遅延を引き起こすことを経験したので、音声の途切れはありませんが、音声の遅延はあります.ボイスチャットサーバー/クライアント通信に最適な構造は何ですか?

これまでのところ、クライアントがデータをudpパケットとしてサーバーに送信し、サーバーがTCPストリームを介してクライアントにパケットを配布する場合、これは適切な解決策ですか? つまり、これは商用のボイスチャット アプリケーションが行うことですか?

あなたの答えは私と他の多くのプログラマーに役立ちます。

JF

4

2 に答える 2

1

質問が3年遅れているようですが、回答が受け入れられていないようなので、試してみます

1-あなたの発言は正しい

2- 正しい、TCP または UDP をオーディオ ストリームに使用できます。

3- オーディオ ストリームに tcp と udp を組み合わせても役に立ちません。UDP がサーバーへの送信に機能している場合、受信にも機能します。これがすべての NAT ファイアウォールの機能です。つまり、内部ホストから受信したデータグラムを、IP ヘッダーを変更してリモート ホストに送信し、パケットが送信されたように見せかけます。応答を受信すると、それを内部ホストに転送します。NAT ファイアウォールの違いは、NAT トンネルが存続する時間の長さです。ただし、通話中は音声が常に双方向に流れているため、通話の音声部分については問題ありません。これは、SIP プロトコルを使用するコールのシグナリング部分にとってより重要です。したがって、TCP セッションのデフォルトのタイムアウトは 900 秒であり、キープ アライブ メッセージの必要性が低くなるため、SIP に TCP を使用することをお勧めします。

あなたが言及した一部のアプリケーションは、セッションの開始に SIP を使用しないため、独自のシグナリング方法があります。

Skype などの他のアプリケーションは、「ホール パンチング」と呼ばれるものを利用して、クライアントからクライアントへの直接通信 (またはピア ツー ピア) を可能にします。これらの利点は、サーバーが音声ストリームの途中にとどまらないことです。これにより、待ち時間が効果的に短縮され、TCP がオーディオ ストリームの選択肢となる可能性があります。

有名なオープンソース PBX であるアスタリスクの開発者たちは、多くのポートを開く必要がある SIP の問題を認識し、IAX と呼ばれる独自のプロトコルを開発して、1 つのポートでシグナリングとメディアを送信しました。クライアント/サーバーに IAX を実装することを検討することをお勧めします。これにより、クライアントが (シグナリングを介して) 接続できる場合、呼び出しを行うことができるようになります。

于 2013-12-03T12:04:06.537 に答える