![]() |
Version 5.1 |
|||||||||||||||||||||||||||||
|
|
従来の基本的なSIP コミュニケーションモデルでは、エンドポイント(終点) 間で直接通信が実行さ れること、つまり「要素」(電話機やソフトフォン、PBX アプリケーションなどのSIP クライアント) とSIP サーバーの間では実際のインターネットIP アドレスを使って通信が行われることを前提とし ていました。この方式の場合、サーバー(SIP プロキシ) はコールの確立の際にのみ必要です。その 後は、エンドポイント間で直接、メディアデータや受信コールシグナリング要求が送信されます。
CommuniGate Pro は自動「NAT トラバーサル」をサポートしており、この機能を介してスタンダード ベースのリアルタイムコミュニケーションが実行されます。
NAT の一方の側から他方の側にセッション開始要求が送信される(例えばLAN クライアントからイ ンターネット/WAN 側に送信、またはその逆) と、その要求がCommuniGate Pro のSIP モジュール によって検出されます。同時に、CommuniGate Pro サーバーによりローカルサーバーのポート(また はメディアプロトコルによってはポートのセット) を使ってメディアストリームプロキシが構築され ます。続いてセッション開始要求が編集され、以後、両方の側からのトラフィックが、そのメディア ストリームプロキシに送られるようになります。つまり、メディアストリームプロキシは、メディア 接続上の「LAN の足」と「WAN の足」の間でメディアをリレーするという処理を行います。
また、セッション再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.
CommuniGate Pro のSIP モジュールにはまた 「ファーエンド」NAT トラバーサル機能もあり、この
機能によって、リモートファイアウォール/NAT の背後にあるクライアントからの要求を検出できま
す。
上記の要求にはRecord-Route とPath の各ヘッダが付加されます。また、メディアプロキシが構築さ
れ、そのプロキシを介してクライアントからのトラフィック、クライアントへのトラフィックがリ
レーされます。
注意: 最近の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 トラバーサルが可能になります。
エッジサービスでは、LAN 内部からのコールがメディアプロキシを介してWAN に送信され、再度 WAN からメディアプロキシを介して同じLAN にコールが送信されることもありますが(つまり LAN 内部での通信)、この処理は「メディアループ」として認識されます。その場合、そのメディア プロキシは削除されます。この仕組みにより、プロキシの不要なオーバーヘッドがなくなります。ま た、同一のLAN 内の2 つのSIP クライアントによって直接通信が実行されます。この場合でも、 LAN の外部のサーバーのレジストラサービスに対するアクセス(REGISTER 要求の送信) は可能で す。
SIP モジュールには、上記のメディアループよりはるかに複雑なループを検出する機能もあり、この 検出によりメディアプロキシの使用が完全に排除され、オーバーヘッドをなくすことができます。ま たは、使用されるメディアプロキシの数が最小限に抑えられます。