5

NAT ホール パンチング、ICE、SIP VOIP 通話の詳細の多くを理解しています。これらのトピックに関するSOに関するかなりの数の質問に答えました。質問があります。

コールがすでに確立された後、SIP+ICE について文書化されている RE-INVITE メッセージの必要性を理解しようとしています。

メディア接続を確立するために、SIP を介して信号を送信し、ICE (STUN/TURN を使用) を使用する VOIP デバイスのトポロジを想定します。ICE 接続チェックが実行されると、両方のエンドポイントが最適なアドレス候補の組み合わせ (IP、ポート) を確認し、双方向でメディアをストリーミングする準備が整うはずです。

しかし、SIP での私の経験と多くの文書によると、呼び出し先が 200 OK メッセージを送信して応答状態であることを示した後、呼び出し元は、接続チェックによって選択された特定のアドレス候補を含む SDP を含む RE-INVITE を送信することが期待されます。 .

ICE を使用した RE-INVITE について説明しているリンクは、こことここにあります(ステップ 8)。Rosenberg のチュートリアル(30 ページ) では、RE-INVITE は「ミドルボックスが正しいメディア アドレスを持つことを保証する」と説明しています。なぜそれが重要なのかわかりません。

RE-INVITE を受信すると、受信者は受信した新しい SDP に基づいてソケットまたはアドレスを切り替えるために ICE スタックを再構成する必要がありますか? それとも、RE-INVITE は、呼が確立されたことを正式に確認するための単なるプロトコル形式ですか? RE-INVITE ステップがスキップされ、双方がメディアのストリーミングを開始した場合、何が問題になる可能性がありますか?

私が質問する理由は、SIP ではないシグナリング サービスで ICE を使用することを検討しているためです。RE-INVITE をエミュレートする必要があるかどうかを把握しようとしています。

4

2 に答える 2

5

ICE ネゴシエーションの結果に関心を持つ可能性があるミドルボックスの一例は、帯域幅マネージャーです。

エンドポイントが企業のファイアウォール内にあり、他のエンドポイントがインターネット上をローミングしている、またはプライベート ホーム ファイアウォールの背後にある、エンタープライズ展開を想像してみてください。展開には、パブリックにアクセス可能な TURN サーバーも含まれます。次に、企業のファイアウォール内のエンドポイントが通話を行っているとします。目的地がたまたま同じネットワーク上で到達可能である場合、呼び出しはホスト間で行われ、TURN サーバーは使用されません (つまり、バインディングが割り当て解除されます)。これはローカル ネットワークであり、帯域幅制限を課す必要はありません。一方、コールがローミング エンドポイントに発信されると、TURN サーバーが関与し、データはおそらく帯域幅が制限されたアップリンクを通じて、企業のファイアウォールを通過します。通話の帯域幅を制限したいポリシーがあることは十分に想像できます。それを行う1つの方法、

一般的な意図は、ICE に対応していないそのタイプのレガシー機器は、ICE エンドポイントを導入する混合環境で動作し続ける必要があるということだったと思います。この下位互換性を維持するために、ICE は新しい処理 (STUN チェックなど) のみを導入する必要がありますが、ICE を認識しない要素の観点からは、既存のルールを削除しないでください (メディア ストリームの宛先）。

于 2013-04-15T15:10:27.083 に答える