セッション境界コントローラによる NAT トラバーサル

ネットワーク アドレス トランスレータ(NAT) は、企業またはオペレータのネットワークを 1 つまたは複数の IP アドレスの背後に隠すことによって、IPv4 アドレスの可用性の欠如を克服するために使用されます。NATの背後にあるデバイスは、パブリック インターネットでルーティングできないプライベート IP アドレスを使用します。セッション開始プロトコル(SIP) は、 Voice over IP (VoIP) 通信の事実上の標準としての地位を確立しています。^[1]通話を確立するために、発信者は自分の IP アドレスを含むSIPメッセージを送信します。着信者は、受信した SIP メッセージに含まれる IP アドレス宛ての SIP メッセージで応答することになっています。発信者が NAT の背後にいてプライベート IP アドレスを使用している場合、これは明らかに機能しません。

SIP 設計における最大の誤りは、おそらく NAT の存在を無視したことだろう。この誤りは、IP アドレス空間が急速に枯渇し、IPv6へのグローバルなアップグレードが必要となり、NAT は不要になるというIETF のリーダーシップの考えから生じた。SIP 標準では NAT が存在しないものと想定されていたが、この想定は失敗に終わった。NAT を使用しているインターネット ユーザーの大半にとって、SIP は単純に機能しなかったのだ。同時に、標準化のライフサイクルが市場の動向よりも遅いことが明らかになった。セッション ボーダー コントローラ(SBC) ^[2]が誕生し、標準が対応できなかったNAT トラバーサルの修正が開始された。

ユーザー エージェントが NAT の背後にある場合、連絡先およびヘッダー経由の連絡先アドレスとしてプライベート IP アドレスとSDP部分が使用されます。この情報は、パブリック インターネットからこのユーザー エージェントに接続しようとするユーザーにとって役に立たなくなります。

NATトラバーサルソリューションには、 STUN、TURN、ICEなどがあります。 ^[3]どのソリューションを使用するかは、NATの動作と通話シナリオによって異なります。SBCを使用してNATトラバーサルの問題を解決する場合、SBCの最も一般的なアプローチは、ユーザーエージェントのパブリックインターフェイスとして機能することです。^[4]これは、ユーザーエージェントの連絡先情報をSBCの連絡先情報に置き換えることで実現されます。

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 は登録情報のローカル コピーを保持します。SBC は、受信した各 REGIETER 要求をオペレータの登録サーバーに転送する代わりに、かなり長い時間間隔 (数時間の範囲) でのみ REGISTER 要求を登録サーバーに送信します。コンテンツ登録情報を変更しないユーザー エージェントから受信した登録要求には、SBC 自体が応答します。SBC は、ローカル登録の有効期限が切れたり変更されたりすると、登録サーバーに通知します。

登録の場合と同様に、SBC はINVITEやその他の要求メッセージのパスに自身を含めます。NAT の背後にあるユーザー エージェントから INVITE を受信すると、SBC は自身のアドレスを含む via ヘッダーを含め、contact ヘッダーの情報を自身のアドレスに置き換え、SDP本文のアドレス情報も自身のアドレスに置き換えます。これにより、すべての SIP メッセージとメディア パケットが SBC を通過するようになります。

SIP を使用して通話が確立されると、音声、ビデオ、またはデータなどのメディア パケットが、通常はリア​​ルタイム トランスポート プロトコル(RTP) を使用して交換されます。SIP メッセージの NAT トラバーサルは結局のところ複雑に思えるかもしれませんが、さらに複雑なタスクは、メディアが NAT をトラバースできるようにすることです。最初の問題の説明は同じです。NAT の背後にある SIP デバイスが IP アドレスをアドバタイズすると、NAT の反対側にあるピアはトラフィックをそのデバイスにルーティングできません。SBC に付属するソリューションは、SIP の動作方法を単に無視しています。SIP SDP 本文でアドバタイズされた IP アドレスとポート番号にメディアを送信する代わりに、SBC はユーザー エージェントのメディアを、エージェントが独自のメディアを送信した場所に対称的に返します。この対称通信は、VoIPの登場前に NAT 製造元が慣れ親しんでいたトラフィック パターンであるため、通常は機能します。

これは大抵は機能しますが、いくつかの制限があることを知っておくことが重要です。まず、これは「対称的な方法」で構築されたクライアント、つまりメディアの送受信に同じポートを使用するクライアントでのみ機能します。幸いなことに、現在利用可能な機器の大部分は対称的な方法を採用しています。

もう一つの顕著な欠点は「三角ルーティング」です。SBC は、通話のすべての VoIP トラフィックを中継して、発信者 - SBC と SBC - 着信者のパスを対称にする必要があります。これは、VoIP オペレータにとって、実際にはかなりのオーバーヘッドです。最も一般的なコーデックであるG.711では、中継された通話は、発信 2 つと着信 2 つの合計 4 つの 87.2 kbit/s ストリームを消費します。

他にも、いくつかの厄介な制限が発生する場合があります。たとえば、SIP デバイスが音声アクティビティ検出(VAD) を使用していて、最初に音声パケットを送信できなかった場合、SBC はそのアドレスを学習せず、着信メディアも転送しません。