SIPベースのソリューションを実装し、RTPProxyで動作するようにセットアップを構成しました。現在、ICEに依存するメディアトランスポートで問題が発生していたため、RTPProxyを介してすべてをルーティングしています。誤解しない限り、対称NATの背後にある2つのクライアント間でストリーミングデータを中継するには、中央中継サーバーが必要です。実際には、これはすべての消費者ユーザーの大部分ですか?必要のないときにリレーサーバーをスキップする適切なルーティングを実装した場合に節約できる帯域幅はどれくらいですか。私たちが見逃しているより良い解決策はありますか?
4 に答える
有用性の高い順に:
- 両方向の 2 つのエンドポイント間に直接接続があります。接続するだけで、基本的に完了です。
- 2 つのエンドポイント間に一方向の直接接続があります。その場合は、両方を試して正しい方向に接続するだけです。
- どちらの当事者も、ある種の NAT の背後にあります。
- 幸いなことに、UPnP は一方の端で動作します。その後、接続を上記のスキームにアップグレードできます。
- UPnP は機能しませんが、STUNは機能します。これを使用して、NAT に穴を開けます。いくつかの異なるプロトコルがありますが、一般的な秘訣は、NAT ピアシングを調整する仲介者を介して交渉することです。
- フォールバックして、ネットワーク上の別のノードを中継プロキシとして機能させます。
上記の完全なリストを実装すると、ほとんどの接続を放棄する必要がなくなり、プロキシでの帯域幅の使用に多くの時間を費やす必要がなくなります。私がある程度知っている BitTorrent プロトコルは、通常 UPnP で停止しますが、NAT を介した接続をテストする組み込みのテストを提供します。
なぜ IPv6 が以前に実装されなかったのか、本当に疑問に思います。これはプログラマーの時間の無駄です。
Google によると、トラフィックの約 8% を中継する必要があります: http://code.google.com/apis/talk/libjingle/important_concepts.html
ホーム ユーザーの大部分 (過半数ではないにしても) が NAT を使用しています。これは、xDSL/ケーブル ルーターがローカル ネットワークへのネットワーク アクセスを提供するために使用するものであるためです。
理論的には、UPnP を使用してポートを開き、ルーターで転送ルールを設定して、NAT を透過的に通過させることができます。残念なことに (または、あなたが誰であるかによっては幸いなことに)、多くのユーザーはルーターで当然のこととして UPnP を無効にしており、転送ルールを手動で追加する必要があることに感謝していない可能性があります。
あなたができるかもしれないこと(そしてSkypeがAFAIKで行っていること)は、明確なネットワークパスと十分な帯域幅を持つユーザーの一部をリレーノードとして機能させることです. ルーティングと QoS の問題とは別に、中継ノードの所有者を含め、誰からも中継データのプライバシーを確保する方法を少なくとも見つける必要があります。さらに、このアプローチでは、技術的な問題とは別に、解決すべき法的な問題が発生する可能性があります。