NAT_traversal_with_session_border_controllers
「セッション ボーダー コントローラーによる NAT トラバーサル」 –
ネットワーク アドレス トランスレータ(NAT) は、1 つまたは少数のIP アドレスの背後にある企業またはオペレーターのネットワークを隠すことによって、 IPv4アドレスの可用性の欠如を克服するために使用されます。NATの背後にあるデバイスは、パブリック インターネットでルーティングできないプライベート IP アドレスを使用します。Session Initiation Protocol (SIP) は、 Voice over IP (VoIP) 通信の事実上の標準としての地位を確立しています。通話を確立するために、発信者はSIPを送信します。メッセージには、独自の IP アドレスが含まれています。呼び出し先は、受信した SIP メッセージに含まれる IP アドレス宛ての SIP メッセージで応答することになっています。発信者が NAT の背後にあり、プライベート IP アドレスを使用している場合、これは明らかに機能しません。
おそらく、SIP 設計における最大の間違いは、NAT の存在を無視したことです。このエラーは、IP アドレス空間がより急速に使い果たされ、 IPv6へのグローバルなアップグレードが必要になり、NAT の必要性がなくなるというIETFリーダーシップの信念から生じました。SIP 標準は、NAT が存在しないことを前提としており、これは失敗であることが判明しました。SIP は、NAT の背後にいる大多数のインターネット ユーザーにとって単純に機能しませんでした。同時に、標準化のライフ サイクルが市場の動きよりも遅いことが明らかになりました。Session Border Controllers (SBC) が誕生し、標準が失敗したこと、つまりNAT トラバーサルを修正し始めました。
ユーザー エージェントが NAT の背後に配置されている場合、連絡先の連絡先アドレスとして、ヘッダーとSDP部分を介してプライベート IP アドレスを使用します。この情報は、公共のインターネットからこのユーザー エージェントに接続しようとしている人にとっては役に立ちません。
STUN、TURN、ICEなど、さまざまな NAT トラバーサル ソリューションが使用するソリューションは、NAT の動作と通話シナリオによって異なります。SBCを使用して NAT トラバーサルの問題を解決する場合、SBC の最も一般的なアプローチは、ユーザー エージェントのパブリック インターフェイスとして機能することです。これは、ユーザー エージェントの連絡先情報を SBC の連絡先情報に置き換えることによって実現されます。
コンテンツ
1 ユーザー登録と NAT トラバーサルの SBC 処理
2 通話確立と NAT トラバーサルの SBC 処理
3 メディア パケットの SBC 処理と NAT トラバーサル
4 参考文献
ユーザー登録と NAT トラバーサルの SBC 処理
通話確立中の SBC による NAT トラバーサル処理
ユーザー エージェントが SBC のパブリック インターフェイスを介して到達できるようにするために、SBC はユーザー エージェントの登録情報を操作します。ユーザーは、REGISTER要求の連絡先情報としてプライベート IP アドレスを含めます。このアドレスへの呼び出しは、パブリックにルーティングできないため、失敗します。SBC は、連絡先ヘッダーの情報を独自の IP アドレスに置き換えます。これがレジストラに登録される情報です。ユーザー宛ての通話は、SBC に転送されます。
どのユーザー エージェントが実際に接続されているかを SBC が知るために、SBC はユーザー エージェントの登録のローカル コピーを保持できます。ローカル コピーには、プライベート IP アドレスとユーザーのSIP URI、および NAT によって SIP メッセージに割り当てられた IP ヘッダーに含まれるパブリック IP アドレスが含まれます。
あるいは、SBC はこの情報を転送された SIP メッセージに保存することもできます。これを図に示します。ユーザーの連絡先情報は特別な形式で結合され、追加パラメーターとして連絡先ヘッダーに追加されます。連絡先情報には、ユーザーのプライベート IP アドレスと SIP URI、および SIP メッセージの IP ヘッダー内のパブリック IP アドレスが含まれます。レジストラがユーザーの要求を受信すると、レジストラは完全な連絡先情報をプロキシに返します。プロキシは、この情報を SIP メッセージに含めます。次に、SBC は SIP 要求からこの情報を取得し、それを使用して要求をユーザーに適切にルーティングできます。
ユーザー エージェントの連絡先情報を登録済みの連絡先情報に追加することには、多くの利点がSBC はローカルの登録情報を保持する必要がないため、このソリューションは実装が簡単で、情報を保持するためのメモリを必要としません。さらに、ユーザー エージェント宛ての要求は、必ずしもユーザー エージェントの登録メッセージを処理した SBC を通過する必要はありません。ユーザー エージェントに到達できる SBC は、SIP 要求に含まれる情報に基づいて、ユーザー エージェント宛てのメッセージを正しくルーティングできます。ただし、この利点は一部の場合にのみ適用されます。ユーザー エージェントの前で使用される NAT が、ユーザー エージェントが以前に接続した IP アドレスからのトラフィックのみを受け入れる場合、ユーザー エージェントの REGISTER 要求を処理した SBC のみがユーザー エージェントに接続できます。
もう 1 つのオプションは、登録情報のローカル コピーを保持することですが、SBC での処理要件が増加する可能性がSBC は、ローカル登録データベースを管理する必要がメモリ要件に加えて、SBC は、この情報を高可用性にするためにバックアップ システムに複製する必要がこれにより、SBC の処理要件がさらに増加し、帯域幅の消費が増加します。
ただし、登録情報のローカル コピーを保持することにも利点がユーザー エージェントからメッセージを受信すると、ネットワーク アドレス トランスレータは、ユーザー エージェントのプライベート IP アドレスをパブリック IP アドレスにバインドします。このバインディングは、一定期間アクティブなままになります – バインディング期間。ユーザー エージェントがバインディング期間よりも長い期間メッセージを送受信しない場合、NAT はバインディングを削除し、ユーザー エージェントは外部から到達できなくなります。バインディングをアクティブに保つために、ユーザー エージェントは定期的にリフレッシュする必要がこれは、バインディング期間よりも短い時間間隔で REGISTER 要求を送信することによって実現されます。通常、REGISTER メッセージは認証される必要があるため、頻繁に送信される REGISTER メッセージを処理する必要があると、オペレーターのインフラストラクチャのパフォーマンスが低下します。SBC は、この負荷をオフロードするのに役立ちます。ユーザー エージェントが最初の REGISTER 要求を送信すると、SBC は REGISTER 要求をオペレーターの登録サーバーに転送します。登録が正常に認証され、オペレーターによって受け入れられると、SBC は登録情報のローカル コピーを保持します。各着信 REGIETER 要求をオペレーターの登録サーバーに転送する代わりに、SBC は REGISTER 要求のみをかなり大きな時間間隔 (時間の範囲) で登録サーバーに送信します。コンテンツの登録情報を変更しないユーザー エージェントからの登録要求は、SBC 自体によって応答されます。SBC は、ローカル登録が期限切れになるか変更されると、登録サーバーにも通知します。
通話確立と NAT トラバーサルの SBC 処理
ユーザー登録時のSBCによるNATトラバーサル
登録の場合と同様に、SBC もINVITEおよびその他の要求メッセージのパスに自身を含めます。NAT の背後にあるユーザー エージェントから INVITE を受信すると、SBC は独自のアドレスを持つ via ヘッダーを含め、contact ヘッダーの情報を独自のアドレスに置き換え、SDP本文のアドレス情報も独自のアドレスに置き換えます。これにより、すべての SIP メッセージとメディア パケットが SBC を通過します。
メディア パケットの SBC 処理と NAT トラバーサル
SIP を使用した通話の確立後、メディア パケット、つまり音声、ビデオ、またはデータが交換されます。通常はリアルタイムトランスポート プロトコル(RTP) を使用します。SIP メッセージの NAT トラバーサルは結局複雑に見えるかもしれませんが、さらに複雑なタスクはメディアが NAT を通過できるようにします。最初の問題文は同じです。NAT の背後にある SIP デバイスが IP アドレスをアドバタイズすると、NAT の反対側にあるピアはそれらにトラフィックをルーティングできません。SBC に付属するソリューションは、SIP の機能を単純に無視しています。SIP SDP ボディでアドバタイズされた IP アドレスとポート番号にメディアを送信する代わりに、SBC はユーザー エージェントのメディアを、エージェントが独自のメディアを送信した場所に対称的に送信します。この対称通信は、 VoIPが登場する前に NAT メーカーが慣れていたトラフィック パターンであるため、通常は機能します。
これはほとんど機能しますが、いくつかの制限があることを知っておくことが重要です。まず、「対称的な方法」で構築されたクライアントでのみ動作します。つまり、メディアの送受信に同じポートを使用します。今日では幸いなことに、それが利用可能な機器の大部分です。
もう 1 つの顕著な欠点は、「三角ルーティング」です。SBC は、呼び出しのすべての VoIP トラフィックを中継して、呼び出し元 – SBC と SBC – 呼び出し先のパスを対称にする必要が実際、これは VoIP オペレータにとってかなりのオーバーヘッドです。最も一般的なコーデックであるG.711では、中継された通話は 4 つの 87.2 kbit/s ストリーム (発信 2 つ、着信 2 つ) を消費します。
他のいくつかの不穏な制限も発生する可能性がたとえば、SIP デバイスがVoice Activity Detection（VAD;音声アクティビティ検出）を使用していて、最初に音声パケットを送信できなかった場合、SBC はそのアドレスを学習せず、着信メディアも転送しません。
参考文献
^ ジンライヒ、ヘンリー。Johnston、Alan B. （2001)、SIP を使用したインターネット通信、Wiley、p. 180、 ISBN 0-471-77657-2
^ 「セッション ボーダー コントローラーについて」 (PDF) . ^ ローゼンバーグ、J. . 対話型接続確立 (ICE): オファー/アンサー プロトコルのネットワーク アドレス トランスレータ (NAT) トラバーサルのプロトコル。IETF。RFC5245 ^ ハウタコルピ、J.; カマリロ、Ｇ．ペンフィールド、R.; Hawrylyshen、A。Bhatia、M. 。SIP (Session Initiation Protocol) セッション ボーダー コントロール展開の要件。IETF。RFC5853″