CommuniGate Pro
Version 5.1
シグナル
 
 
 
NAT

NAT トラバーサル

オリジナルもしくは「基本的」なVoIP コミュニケーションモデルでは、エンドポイント同士で直接、 通信が可能ということが前提になっています。つまり、エンティティ(電話やソフトフォン、PBX アプリケーションなどのクライアント) とサーバーにはすべて「実」インターネットIP アドレスが あります。このIP アドレスを使うことで、エンティティ同士でメディアデータの直接交換が可能に なり、その結果、メディアパケット(通常、RTP プロトコルまたはT.120 プロトコルを使用) がエ ンティティティ間で直接、相互に送信されます。

ただし、上記の前提は、実際にはほとんど当てはまりせん。つまり、エンドポイント間ではメディ アデータの直接交換・送信は実際には不可能なのです。CommuniGate Pro サーバーでは、この問題を 解決しています。方法は、メディアプロキシを自動的に生成し、そのメディアプロキシに対してエ ンドポイントからメディアデータを送信するというものです。メディアデータは、その後、メディ アプロキシからリレーされます。

メディアプロキシは、次の場合に生成されます。
  • 一方のエンドポイントがLANに接続されており、他方のエンドポイントがWANに存在している場合。
  • 一方のエンドポイントがリモートのNATの背後にあり、他方のエンドポイントが、その NAT の背後にない(NAT で分離されている) 場合。
  • 一方のエンドポイントがIPv4 ネットワーク上にあり、他方のエンドポイントがIPv6 ネット ワーク上にある場合。
  • CommuniGate Pro のSignal コンポーネントが明示的にメディアプロキシの生成を要求した場合。

メディアプロキシは、コールがリモートエンティティに対して確立されるときにSIP とXIMSS の各 コンポーネントによって生成されます。

NAT トラバーサルとメディアストリームプロキシ

従来の基本的なSIP コミュニケーションモデルでは、エンドポイント(終点) 間で直接通信が実行さ れること、つまり「要素」(電話機やソフトフォン、PBX アプリケーションなどのSIP クライアント) とSIP サーバーの間では実際のインターネットIP アドレスを使って通信が行われることを前提とし ていました。この方式の場合、サーバー(SIP プロキシ) はコールの確立の際にのみ必要です。その 後は、エンドポイント間で直接、メディアデータや受信コールシグナリング要求が送信されます。

Basic SIP Call

CommuniGate Pro は自動「NAT トラバーサル」をサポートしており、この機能を介してスタンダード ベースのリアルタイムコミュニケーションが実行されます。


ニアエンドNAT トラバーサル

NAT の一方の側から他方の側にセッション開始要求が送信される(例えばLAN クライアントからイ ンターネット/WAN 側に送信、またはその逆) と、その要求がCommuniGate Pro のSIP モジュール によって検出されます。同時に、CommuniGate Pro サーバーによりローカルサーバーのポート(また はメディアプロトコルによってはポートのセット) を使ってメディアストリームプロキシが構築され ます。続いてセッション開始要求が編集され、以後、両方の側からのトラフィックが、そのメディア ストリームプロキシに送られるようになります。つまり、メディアストリームプロキシは、メディア 接続上の「LAN の足」と「WAN の足」の間でメディアをリレーするという処理を行います。

Near End NAT SIP Traversal

また、セッション再INVITE 要求とBYE 要求もCommuniGate Pro のSIP モジュールが検出し、その内 容に応じてセッションプロキシ( メディアストリームプロキシ) の更新や削除が行われます。この場 合、タイムアウトの設定にしたがって「放棄」されたメディアストリームプロキシが削除されます。

CommuniGate Pro では、次の各プロトコル用のNAT プロキシサービスが用意されています。

注意: メディアストリームプロキシ機能を使用する場合、LAN/NAT データに関する設定が必要です。この 設定は、[LAN IPs] 設定ページで行えます。

注意: The Server automatically builds Media Proxies when it relays requests from IPv4 addresses to IPv6 addresses and vice versa.


ファーエンドNAT トラバーサル

CommuniGate Pro のSIP モジュールにはまた 「ファーエンド」NAT トラバーサル機能もあり、この 機能によって、リモートファイアウォール/NAT の背後にあるクライアントからの要求を検出できま す。
上記の要求にはRecord-Route とPath の各ヘッダが付加されます。また、メディアプロキシが構築さ れ、そのプロキシを介してクライアントからのトラフィック、クライアントへのトラフィックがリ レーされます。

Far End NAT SIP Traversal

注意: 最近のSIP クライアントでは各種のNAT トラバーサル方式(STUN など) がサポートされて います。ただし多くの場合、かなりバグがあります。そのため、クライアント側のNAT トラバーサ ル方式はオフにし、CommuniGate Pro のSIP モジュールのファーエンドNAT トラバーサル機能を使 用するのが無難です。

注意: TCP プロトコルとファイアウォールの仕様により、TCP を介してファーエンドNAT の背後に あるクライアントに接続することはできません(ニアエンドNAT では、この問題は発生しません)。 言い換えれば、ファーエンドNAT の背後にあるクライアントに対してTCP (T.120) セッションを 開始することはできません。ただし、この問題は、次のいずれかの方法で解決できます。


エッジサービス

CommuniGate Pro のSIP モジュールには、「エッジサービス」つまりALG (アプリケーションレベル ゲートウエイ) の機能もあります。この機能により、別のサーバー(別のCommuniGate Pro) のユー ザーにとって、CommuniGate Pro サーバー(エッジサービスを提供するCommuniGate Pro) に対する NAT トラバーサルが可能になります。

SIP Edge Services

エッジサービスでは、LAN 内部からのコールがメディアプロキシを介してWAN に送信され、再度 WAN からメディアプロキシを介して同じLAN にコールが送信されることもありますが(つまり LAN 内部での通信)、この処理は「メディアループ」として認識されます。その場合、そのメディア プロキシは削除されます。この仕組みにより、プロキシの不要なオーバーヘッドがなくなります。ま た、同一のLAN 内の2 つのSIP クライアントによって直接通信が実行されます。この場合でも、 LAN の外部のサーバーのレジストラサービスに対するアクセス(REGISTER 要求の送信) は可能で す。

Collapsing Media Proxy

SIP モジュールには、上記のメディアループよりはるかに複雑なループを検出する機能もあり、この 検出によりメディアプロキシの使用が完全に排除され、オーバーヘッドをなくすことができます。ま たは、使用されるメディアプロキシの数が最小限に抑えられます。


CommuniGate® Pro Guide. Copyright © 1998-2007, Stalker Software, Inc.