Windows XP の Windows Messenger: ファイアウォールおよびネットワークアドレス変換での動作

Windows XP の Windows Messenger: ファイ...

概要

この記事は複数のシナリオを考察し、Windows Messenger のすべての機能を使用する際に必要となる事項について述べると共に、特定の問題に対する可能な解決策を示します。

トピック

はじめに
 NAT とファイアウォールの問題点
 NAT と Windows Messenger
ファイアウォールと Windows Messenger
Windows Messenger の設定 : 動作する場合と動作しない場合
 ソリューション
 Microsoft Internet Security and Acceleration (ISA) サーバーのオーディオとビデオ
 まとめ
 略語集
 関連リンク

はじめに

この記事では複数のシナリオを考察し、Windows Messenger のすべての機能を使用する際に必要となる事項について述べると共に、特定の問題に対する可能な解決策を示します。

Windows Messenger はユーザーのコミュニケーション方法に変革をもたらす刺激的で新しいリアルタイムな通信環境を提供します。Windows Messenger を使用すると、インスタントメッセージング (IM) によるコンタクト、音声、ビデオ、アプリケーション共有、データ共有、ならびにリモートアシスタンス機能によるコミュニケーションが可能になります。多くのネットワークで、ネットワークインフラストラクチャを変更することなく、この機能すべてを使用できます。企業や住宅などの特定のネットワークにおいて、ファイアウォールやネットワークアドレス変換 (NAT) コンポーネントを配置することも可能です。

ファイアウォールの目的は、直接的なアクセスを阻止することによって、ネットワーク上のコンピュータを保護することです。ファイアウォールの背後にあるコンピュータは、NAT コンポーネントを使用して限られた公開インターネットプロトコル (IP) アドレスを共有します。共有 IP アドレスは現行の IP バージョン 4 (IPv4) アドレス指定スキーマによってインターネット上で課せられている制限です。IPv4 アドレス指定スキーマでは十分な IP アドレスを供給できないため、情報技術業界は NAT を標準化して、IP アドレスと伝送制御プロトコル (TCP) /ユーザーデータグラムプロトコル (UDP) ポートを共有する NAT 製品を導入する必要に迫られました。その結果、主として音声やビデオの即時通信といった Windows Messenger の一部の特徴ある機能では、特定のインターネットシナリオで使用した場合に機能性が下がります。

ユニバーサルプラグアンドプレイ (UPnP) 対応のファイアウォールや NAT コンポーネントを通信者間で使用している場合、Windows Messenger の新機能はすべて意図したとおりに動作します。ただし、ネットワーク設備によっては Windows Messenger の新機能すべてを動作させる際に特別な設定が必要となります。

マイクロソフトは業界大手各社、ならびに Internet Engineering Task Force (IETF) などの標準化団体と協力して、このような充実したコミュニケーションとコラボレーション機能をファイアウォールと NAT の背後で確実に利用できるように努めています。

ページのトップへ

NAT とファイアウォールの問題点

このセクションでは、NAT とファイアウォールの問題点によって影響を受けるインスタントメッセージングとプレゼンス、オーディオおよびビデオ、アプリケーション共有とホワイトボード、ファイル転送、およびリモートアシスタンスといった Windows Messenger 機能について説明します。

Windows Messenger ではテキスト、音声、およびビデオを使用した通信、ファイル転送によるコラボレーション、およびアプリケーションとホワイトボード図形の共有が可能です。

Windows Messenger のすべての機能をシームレスに動作させるには多数の設定が必要です。設定によっては特定の機能が制限される、あるいは動作しない場合もあります。このような問題の一部を解決するには Windows XP および旧バージョン Windows の UPnP インフラストラクチャを利用します。この種の解決法は UPnP のサポートが追加されたインターネットゲートウェイ装置が増えるにつれ、より多く利用されることになります。

注意 : マイクロソフトは Windows XP のインターネット接続の共有 (ICS) とインターネット接続ファイアウォール (ICF) 技術で、UPnP をサポートしています (インターネット接続の共有およびインターネット接続ファイアウォールの詳細については Windows XP Professional および Windows XP Home Edition のセキュリティ最新情報を参照してください)。

以下は NAT とファイアウォールの問題によって影響を受ける Windows Messenger 機能です。

インスタント メッセージングとプレゼンス

通常、IM とプレゼンスではファイアウォールまたは NAT デバイス経由の通信に影響を与える問題はありません。Windows XP クライアントがサーバーとの接続を確立および維持できる場合は、その他の IM とプレゼンスの通信は同じパスに従います。たとえば、Microsoft Exchange IM は Hypertext 転送プロトコル (HTTP) を使用してプレゼンスと IM メッセージを転送すると共に、このメッセージがファイアウォールと NAT デバイスを確実にトラバースできるメカニズムを備えています。このメカニズムには双方向の通信でサーバーと TCP 接続を維持するポーリングと、コールバック配信への固定ポート割り当てが含まれています。

セッション開始プロトコル (SIP) を使用すると、TCP、UDP、または Secure Sockets Layer (SSL) を使用してデータが送信されます。SIP のシグナル化に動的ポートも使用する場合があります。動的ポートはファイアウォール上のポート全体を開くのに必要です。SIP クライアントとサーバー間に NAT デバイスを配置した場合、SIP メッセージに反映されたポートおよびアドレスと、実際のポートおよびアドレスに相違が生じることがあります。Windows Messenger はこの問題を克服するメカニズムを備えていますが、これについてはこの記事で後ほど説明します。

オーディオおよびビデオ

オーディオとビデオの間のセッションをネゴシエートする際、オーディオとビデオの間 (AV) のストリームとして動的ポートを選択したとします。動的ポートを使用すると、ほかのどのアプリケーションがシステム上で動作しポートリソースを使用しているかを問わず、アプリケーションを実行することができます。.NET Messenger の場合、ステーション B がステーション A のものとして受信したアドレスに、ステーション B からセッション要求が送信されます。

以下はこのシナリオでファイアウォールまたは NAT が存在する場合に発生するおそれのある問題点です。

セッションシグナル化でのセッション要求、UDP ストリームでのセッション承諾いずれかによってA が供給したアドレスは、NAT デバイスで変換された内部アドレスになる可能性があります。これは、B が A とのコンタクトに使用するには無効な (偽の) アドレスです。他の 4.5 クライアントのシナリオで A がセッションを開始しても、同様、または類似のアドレス指定問題が生じます。
B がセッション要求を A に送信するときは、A から B に渡した IP アドレスとポートを使用してこの要求を送信します。これを実行するには、このポートが A と B 間のどのファイアウォールも経由できるようにする必要があります。
実際のリアルタイム転送プロトコル (RTP) ストリームは 5004 ～ 65535 の範囲に動的に割り当てられた UDP ポートを使用して送信されます。動的なパス内のどのファイアウォールにも UDP ポートを開放する方法がない場合、ストリームは送信先へのコンタクトに失敗します。

アプリケーション共有とホワイトボード

NAT またはファイアウォール環境でアプリケーション共有とホワイトボードを使用している場合、以下の問題が生じます (最初の 2 つの問題はオーディオおよびビデオで発生する問題と同じです)。

開始ステーションの提供するアドレスが、NAT デバイスで変換された内部アドレスとなる場合があります。これは、外部クライアントが A に対する SIP セッションまたは TCP 接続の開始に使用するには、無効なアドレスです。
内部クライアントによって外部クライアントに渡された SIP 要求を外部クライアントが送信する際に使用するポートでは、クライアント間のファイアウォール経由での SIP 要求の受け渡しを許可できるようにしておく必要があります。
アプリケーション共有 (AS) とホワイトボード (WB) データの TCP 接続には、あらゆるファイアウォールをトラバースできるようにポート 1503 を使用します。これは内部の静的ポートを別のポートに割り当てる UPnP 対応ゲートウェイの場合には当てはまりません。
TCP データ接続では専用のポート (1503) が使用されるので、クライアントが UPnP 非対応の NAT デバイスの背後にある場合、このポートを該当するクライアントに割り当てる必要があります。これにより共通項の NAT デバイス経由で通信を確保することができます。通常、このことは NAT デバイス背後の別のクライアントはこのポートを使用できないことを意味します。すなわち、同じ NAT デバイス背後のクライアント 1 台だけが AS または WB とのアクティブなセッションを所有できます。

ファイル転送

ファイル転送 (FT) では、サーバー経由のセッション交換において、開始ステーションがアドレスを FT ピアに渡す必要があります。その理由はアプリケーション共有とホワイトボードで最初に列記した問題点が当てはまるためです。

開始ステーションの提供するアドレスが NAT デバイスで変換された内部アドレスとなる場合があります。これはピアが TCP 接続に使用するには無効なアドレスです。

ファイル転送の TCP 接続を外部クライアントが開始した場合、それ以外にも問題が生じます。

TCP 接続の送受信両方で 6891 から 6900 の範囲のポートを使用します。これにより、送信者あたり最大 10 のファイル転送を同時に処理することができます。ピア間のすべてのファイアウォールにこのポートを開放する必要があります。ポート 6891 しか開放していない場合、ユーザーは一度に 1 回のファイル転送しか行うことができません。

リモート アシスタンス

リモートアシスタンスはリモートデスクトッププロトコル (RDP) を利用します。これは Microsoft ターミナルサービスで使用するものと同じプロトコルです。RDP はTCP 接続の最上位に構築されます。Windows Messenger は FT と類似した、サーバーベースのセッション要求ロジックを使用してリモートアシスタンスのセッションを確立します。そのため、このシナリオでも NAT アドレスに関する問題が当てはまります。

リモートアシスタンスでは NAT シナリオに対応するため、追加のロジックが必要です。このロジックは単に両方のクライアントから TCP 接続の確立を試みます。この方法では、クライアントの一方が NAT の背後にある場合には引き続き接続が確立され、リモートアシスタンスを実行することができます。両方のクライアントが (UPnP 非対応の) NAT の背後にある場合、接続は確立されません。追加の SIP 要求ロジックはリモートアシスタンスをサポートする際に音声セッションを追加した場合のみ付加されます。

NAT アドレスが原因で発生する問題以外にも、マルチ NAT デバイスでの通信パスに限られた問題として TCP ポート 3389 がリモートアシスタンスプロトコルの TCP 接続に使用される点が挙げられます。これはポート 3389 をクライアント間のすべてのファイアウォールに開放する必要があることを意味します。

ページのトップへ

NAT と Windows Messenger

このセクションでは NAT デバイスの問題と設定を取り上げます。

NAT デバイスを原因とする問題

Windows Messenger 機能と関連して NAT デバイスで生じる固有の問題は、以下のとおりです。

NAT デバイスの背後にあるクライアントには、通常プライベート IP アドレスが割り当てられています。このアドレスは NAT デバイスによってパブリック IP アドレスおよびポートと相互変換されます。ピアがクライアントにコンタクトできるように、このプライベートアドレスが Windows Messenger ピアへのメッセージに存在する場合があります。このアドレスはここで使用するには無効なアドレスです。代わりに変換されたアドレスを使用する必要があります。
外部クライアントにアドレスとポートを送信して適切な内部クライアントに割り当てるには、NAT デバイスによるポートマッピングの実行が必要な場合があります。
特定の機能で静的ポートを使用している場合、NAT の背後にある 1 台のクライアントのみがこの機能を使用することができます。

さまざまな NAT デバイス設定での動作

以下のセクションではさまざまな NAT デバイス設定に関連した問題について述べます。

UPnP 対応 NAT デバイス

UPnP フォーラムはインターネットゲートウェイデバイス専門の委員会をはじめ複数の運営機構で構成されています。このグループは NAT デバイスとファイアウォールデバイスを含む UPnP 対応デバイスのサポートに関する詳細を定義する役割を果たしています。UPnP フォーラムでは UPnP を利用した ICS と NAT ネットワークトラバースの標準を定義しました。

この標準をサポートする NAT デバイスとファイアウォールデバイスは UPnP プロトコルを利用して検出および制御することができます。クライアント側で UPnP を使用すると、ポートマッピングの読み取りおよび設定が可能になります。Windows XP の ICS と ICF はこの標準をサポートします。ARESCOM Inc.、Buffalo Technologies Corp.、D-Link Systems Inc.、Intel Corp.、Linksys Group Inc.、NetGear Inc など、他のネットワーク端末デバイスのベンダーもこの標準のサポートを発表しています。

Windows XP はネットワーク上の UPnP 対応 NAT とファイアウォールデバイスを検出および活用するアプリケーション専用に設計された、UPnP とアプリケーションプログラムインターフェイス (API) をクライアントサポートしています。Windows XP の Windows Messenger では、API を使用して以下を実現します。

Windows Messenger のクライアントが NAT デバイスの背後に存在するかを検出し、存在する場合は変換されたアドレスを検索してピアに送信します。これにより先に述べた複数の問題が解決します。
ポートマッピングを取得して、SIP セッション設定などで必要となるシグナル化で使用するポートに動的に割り当てます。これにより外部クライアントをシグナル化し、宛先に届けることができます。
AV、AS、WBなどで利用するメディアストリームが使用する動的ポートのマッピングを取得します。
Windows Messenger ピアが同じ NAT デバイスの背後に存在するかを検出します。存在する場合は、ピアの実際のアドレスを検索して直接通信することができます。

注記 : UPnP クライアントでの NAT トラバースは旧バージョンの Windows (Windows 98、98SE、ME) でもサポートすることができます。

UPnP 非対応の NAT

検出できない NAT デバイスによって切り離された Windows Messenger ピアは、IM とプレゼンスを使用できるようにしておく必要があります。このことは使用されているネットワークサービスが .NET Messenger、Exchange IM、または SIP ソリューションであるかに関係なく当てはまります。サーバーを開放すると通信を確保するクライアントにロジックが追加されるため、SIP サーバーを使用するクライアントも動作します。

この記事で先に述べたような問題は Windows Messenger の他の機能でも発生します。以下の点はこの問題に関連しています。

NET Messenger や Exchange IM の使用時には、クライアントが開始した直接の TCP 接続を利用して仲介サーバー経由で IM とプレゼンスが実行されます。この場合、NAT やファイアウォールの問題は一切生じません。ただし、内部クライアントが NAT 変換されたアドレスをピアに供給できないため、NAT デバイス外部のクライアントが開始したセッションや接続は成功しません。AV の場合、外部クライアントが SIP セッションを開始するクライアントなので、内部クライアントが外部クライアント呼び出しを実行した場合はこの問題が当てはまります。外部クライアントが内部クライアントを呼び出す場合、後のプロセスで障害が発生します。内部クライアントは SIP 要求を外部クライアントに送信できますが、この要求で渡されたアドレスは適切ではありません。
NAT デバイスの同じ側のピア間で実行される呼び出しが動作する必要があります。
SIP のアプリケーション層ゲートウェイ (ALG) によって、この問題が多少緩和される場合があります。ALG は特定のアプリケーションとプロトコルに応じたアプリケーションレベルのフィルタとして使用することができます。

カスケードした NAT デバイス

ネットワークの境界で NAT デバイスではなく UPnP 対応 NAT デバイスを使用している場合でも、NAT をカスケードしている場合、Windows Messenger AV 通信が無効になります。このシナリオでは通信先の Windows Messenger クライアントとのパスに別の NAT デバイスが存在しています。この NAT デバイスはいずれのクライアントからも制御されません。これはインターネットサービスプロバイダ (ISP) のネットワークでも NAT 技術を使用している場合に発生します。これはそれほど頻繁に発生する問題ではありません。この状況に気づいた場合は ISP に問い合わせて問題を検証し、可能な対策を講じてください。

ページのトップへ

ファイアウォールと Windows Messenger

NAT デバイス同様、Windows Messenger を使用して通信を試みるとファイアウォールが原因で問題が生じる可能性があります。ファイアウォールデバイスによって生じる問題は以下のとおりです。

SIP シグナル化で使用するメッセージは、外部クライアントから生じる場合や動的ポートまたはポート 5060 いずれかから任意で送信される場合があります。このメッセージを Windows Messenger クライアントに送信する場合、ファイアウォールにポートを開放する必要があります。たとえば Windows XP で ICF を使用しているときは、デフォルトでポート 5060 がブロックされています。
AV の動的ポートや、AS または WB のポート 1503 のように、メディアストリームなどのデータ用ポートがファイアウォールをトラバースできるようにしておく必要があります。

さまざまなファイアウォール設定での動作

以下のセクションでは、さまざまなファイアウォール設定に関連した問題について述べます。

UPnP 対応ファイアウォール

UPnP 対応ゲートウェイデバイスについては前にこの記事で説明しました。インターネット接続ファイアウォールと呼ばれる Windows XP のファイアウォールは UPnP 対応です。Windows XP の Windows Messenger はシグナル化、接続、またはメディアストリームで必要となるポートを開放することで、この機能を使用します。

UPnP 非対応のファイアウォール

UPnP 非対応のファイアウォールで Windows Messenger の最新機能を使用する場合、オプションが非常に限られます。このトピックで考慮する点は以下のとおりです。

ファイアウォールの同じ側に属するピアが Windows Messenger のすべての機能を使用できるようにします。
ほとんどのファイアウォール設定経由で IM とプレゼンスを実行します。
ファイアウォール経由で双方向の AV をサポートするには、5004 から 65535 間の UDP ポートすべてを開放し、シグナル化 (SIP) とメディアストリーム (RTP) がファイアウォールをトラバースできるようにしておく必要があります。動的ポートを使用しているため、これを行う必要があります。AS と WB もシグナル化に動的ポートを使用します。
FT はファイアウォールの 6891 から 6900 のポートを開放することで実行できます。またリモートアシスタンスはポート 3389 を開放することで実行できます。

カスケードしたファイアウォール

ファイアウォールのカスケードによって、カスケードした NAT デバイスと類似した問題が発生する可能性があります。

Windows XP の UPnP の限界

Windows XP ではローカルインターフェイスで ICF を実行し、ユーザーが管理権限を所有していない場合、Windows Messenger から送信される呼び出しを実行しません。この機能は管理権限を所有するユーザーが実行すると正常に動作します。

注意 : Windows XP Home edition の場合、デフォルトでユーザーに管理権限が付与されています。

ページのトップへ

Windows Messenger の設定 : 動作する場合と動作しない場合

ここでは NAT デバイスとファイアウォールデバイスを使用している場合の Windows Messenger の設定に関する図を示します。この図は動作する設定と動作しない設定に分類されています。

動作する設定

以下の設定はネットワーク上に問題が存在しない場合、正常に動作します。

UPnP 対応 NAT が 1 台の場合

図 1 では Home "A" に UPnP 対応インターネットゲートウェイデバイスが装備されています。Home "B" は直接インターネットに接続され、ゲートウェイデバイスを使用していないパーソナルコンピュータを所有しています。UpnP ゲートウェイによって Home "A" は外部ネットワークアドレスを認識して、必要に応じてマッピングを生成することができます。これにより Home "A" と Home "B" は以下の図 1 に示したような通信を行うことができます。

worki01_01

図 1: UPnP 対応 NAT を 1 台使用

UPnP 対応ゲートウェイ経由で 2 つのホームを接続した場合

図 2 は図 1 と類似していますが、この場合 Home "B" にもインターネットゲートウェイデバイスが含まれています。両方のデバイスが UPnP 対応なので、Home "A" と Home "B" は以下の図 2 に示したように Windows Messenger のすべての機能を使用して相互に通信できます。

worki01_02

図 2: UPnP 対応ゲートウェイ経由の接続

2 台のクライアントが UPnP 対応ゲートウェイの背後にある場合

図 3 はデバイスの同じ側にある 2 台のクライアントを示しています。NAT デバイスが UPnP 対応の場合、両方のクライアントが同じデバイスの背後にあることを認識し以下の図 3 に示したように直接通信することができます。

worki01_03

図 3: 2 台のクライアントが UPnP 対応ゲートウェイの背後にある場合

動作しない設定

以下の設定では IM とプレゼンス以外の Windows Messenger 通信に障害があります。

ISP が NAT を使用している場合

図 4 は前に図 1 で示したシナリオを表したものですが、この場合、Home "A" が利用している ISP も NAT 技術を採用しています。そのため、以下の図 4 に示したように Home A のコンピュータは実際のパブリックアドレスを識別することができません。

worki01_04

図 4: NAT デバイスを使用する ISP

Home "B" が UPnP 非対応 NAT を使用している場合

図 5 は図 2 と類似していますが、この場合 Home "B" の使用する NAT が UPnP をサポートしていないため、Home "B" のパーソナルコンピュータが変換されたアドレスを特定できません。これを図示すると、以下の図 5 のようになります。

worki01_05

図 5: UPnP 非対応 NAT を使用

UPnP 非対応 NAT の場合

図 6 は NAT が UPnP 対応でない点を除き、図 1 と同じです。ここでも変換されたアドレスの特定と Windows Messenger で使用する動的ポートの確立を実行できません。これを図示すると、以下の図 6 のようになります。

worki01_06

図 6: UPnP 非対応 NAT を使用

ページのトップへ

ソリューション

Windows Messenger の通信パスに NAT デバイスまたはファイアウォールデバイスが追加されている場合、さまざまな問題が生じます。このような問題の大半は UPnP 対応インターネットゲートウェイデバイスを使用することで対応できます。多数のベンダーがすでにこの機能をデバイスに組み込んでいるほか、中には既存のアップグレード可能なデバイスへの機能の移植を検討しているベンダーもあります。

参照しやすくするため、以下に問題点とソリューションの要点をまとめています。

NAT デバイス

NAT デバイス背後のクライアントは内部ネットワークで使用できるプライベートアドレスと、NAT デバイスの外部と通信する際にアドレス変換によって供給されるパブリックアドレスを所有しています。クライアント間の AV セッションを確立する際に利用するプロトコルにはアドレス指定情報が含まれています。供給されたこのアドレスが内部のプライベートアドレスとポート番号の場合、パブリックネットワークでは無効になります。これが原因で音声とビデオによる通信が阻止されます。

NAT 問題の対策

UPnP 対応 NAT デバイスによって Windows Messenger はポート番号をネゴシエートして、変換された IP アドレスを使用および特定することができます。これによりクライアントは有効なアドレス指定情報を共有できるので、ユーザーは NAT を介したネットワーク経由で音声とビデオによる通信を行うことができます。

利用可能な NAT ソリューション

Windows XP には ICS の形で UPnP 対応インターネットゲートウェイが含まれています。インターネットゲートウェイデバイスとしてコンピュータを使用している場合、これが簡単な解決策です。他のベンダーは UPnP 対応ゲートウェイデバイスを提供するほか、アップグレードを通じて現在のゲートウェイ製品に UPnP サポートを追加しています。このような製品の詳細情報については、こちらのプレスリリース http://www.microsoft.com/presspass/press/2001/Jul01/07-17GatewayDevicesPR.mspx またはベンダーの Web サイトを参照してください。

その他の NAT デバイスベンダーはアプリケーション層ゲートウェイ (ALG) やアプリケーションフィルタを生成するインターフェイスを提供しています。これは専用プロトコルまたはアプリケーションをサポートするために記述されたデバイスソフトウェアのプラグインで、内部ネットワークと外部ネットワークに適したデータ変換を行います。

管理者とユーザーに必要な措置

特にありません。

問題があると思われる場合はISP に問い合わせるかインターネットゲートウェイのマニュアルを参照して、NAT の使用の有無、UPnP サポートの有無を確認してください。UPnP 対応 NAT を使用している場合、ISP に問い合わせて ISP のネットワークでも NAT を使用しているか尋ねると共に、RTP ベースの AV を有効にする対策があるか尋ねます。

ファイアウォールデバイス

ファイアウォールは IP アドレスおよび TCP/UDP ポートへのトラフィックを阻止して明示的に設定および実行されないようにすることで、内部ネットワーク上のコンピュータを保護します。データまたは接続の送信要求に基づいてトラフィックが許可されると、通常の応答形通信が可能になります。

Windows Messenger では SIP のようなセッション確立プロトコルを利用して、クライアントと通信するようにデータパスが設定される場合があります。一旦このセッションが設定されると、外部クライアントによって通信が開始されます。このような通信はファイアウォールによって阻止されます。さらに Windows Messenger の場合、AV トラフィックに動的ポートを使用しています。これにより利用可能な AV ストリームのポートリソースが確保されますが、どのポートを使用するか認識されないためファイアウォールの問題が複雑化します。

ファイアウォール問題の対策

ここでも UPnP によってこのようなファイアウォール問題を解決することができます。Windows Messenger は UPnP 対応ファイアウォールを検出し、現在の通信ニーズに基づいて適切に設定します。UPnP 対応ファイアウォールが配置されていない場合、目的とする Windows Messenger の機能に必要なプロトコルおよびポートとのトラフィックを許可するようにファイアウォールを設定する必要があります。以下の「管理者とユーザーに必要な措置」を参照してください。

利用可能なファイアウォール ソリューション

Windows XP が備えているファイアウォール (インターネット接続ファイアウォール) は UPnP を使用した設定をサポートします。Windows Messenger はこの機能を検出し、通信を続行できるように適切なポートを開放します。別のベンダーのファイアウォール製品を使用している場合、ベンダーの提供する情報を確認して UPnP のサポートの有無、またはリスト出力されたポートを経由できるようにファイアウォールを設定する方法を調べます。「管理者とユーザーに必要な措置」を参照してください。

管理者とユーザーに必要な措置

UPnP 非対応ファイアウォールを経由した Windows Messenger の音声およびビデオ通信を有効にするには、UDP ポート 5004 ～ 65535 でトラフィックを受信できるようにファイアウォールを設定します。それ以外を目的とする場合は以下のポートを有効にします。

ファイル転送：6891 (6891 から 6900 までのポートを開放すると 10 のファイル転送を同時に処理できます)
アプリケーションとホワイトボードの共有：1503
リモートアシスタンス：3389

問題があると思われる場合は、ファイアウォールベンダーに問い合わせると共に配布されたマニュアルを読み、UPnP をサポートするオプションの有無、固有のポートを許可するファイアウォール設定の方法を確認します。カスケードしたファイアウォールに問題があると思われる場合は ISP に問い合わせます。

ページのトップへ

Microsoft Internet Security and Acceleration (ISA) サーバーのオーディオとビデオ

ファイアウォールおよびプロキシサーバーとして動作する Microsoft ISA サーバーがネットワークの境界に配置され、SIP サーバーソリューションを使用している場合、AV で特別な問題が生じます。どのような問題が生じるかは呼び出すクライアントと関連する SIP サーバーのロケーションによって異なります。

シナリオ

以下の導入シナリオはこの特別な状況を図示したものです。

導入シナリオ 1 : ISA サーバーをファイアウォールおよびプロキシとして使用

この導入シナリオでステーション A が Windows Socket Proxy クライアントを実行している場合、ステーション A からステーション B への呼び出し、またはステーション B からステーション A への呼び出しが成功します。これは、Windows Messenger がローカルアドレスを特定しているためです。

これはソケットを使用してリモートアドレスと SIP サーバーへの接続を行い、使用したローカルアドレスをソケットに要求することで実行されます。この場合、受信したアドレスは ISA サーバーの外部インターフェイスからのアドレスであるアドレス X です。このアドレスとランダムポートはセッション記述プロトコル (SDP) を利用したセッション要求によって、ステーション Bに送信されます。

呼び出しがステーション B で生じると、ステーション A がステーション B に関する多数の情報を受信します。この情報、特にステーション B のアドレスを使用すると、以下の図 7 に示したようにセッション要求 (SDP 情報で 200が可能) に応じてステーション A が使用する必要のあるアドレスを特定できます。

worki01_07

図 7: ファイアウォールおよびプロキシとして ISA サーバーを使用

導入シナリオ 2 : ISA サーバーを使用

このシナリオはシナリオ 1 と多少異なります。ステーション A からステーション B への呼び出しは ISA ファイアウォールにどのポートを開放しても決して成功しません。

ステーション B からステーション A への呼び出しは、ステーション A がプロキシクライアントを使用している場合に限り成功します。ステーション A 呼び出しを生成する場合、リモートアドレスとして使用されるアドレスはローカルの SIP サーバーのアドレスです。受信するアドレスもローカルのものです。このアドレスがステーション B へのセッション要求に追加された場合、B はこの内部アドレスを使用してステーション A にコンタクトすることはできません。その結果、この呼び出しが失敗することになります。ステーション B が呼び出しを開始するときに SDP データから要求される B のアドレスは、導入シナリオ 1 と同様に使用することができます。これを図示すると、以下の図 8 のようになります。

worki01_08

図 8: ISA サーバーを使用

ページのトップへ

まとめ

ページのトップへ

略語集

ALG - アプリケーション層ゲートウェイ

AS - アプリケーション共有

AV - オーディオおよびビデオ

FT - ファイル転送

ICF - インターネット接続ファイアウォール

ICS - インターネット接続の共有

IM - インスタントメッセージング

ISA - Internet Security and Acceleration

ISP - インターネットサービスプロバイダ

NAT - ネットワークアドレス変換

RDP -リモートデスクトッププロトコル

RTC -リアルタイム通信

RTP -リアルタイム転送プロトコル

SDP -セッション記述プロトコル

SIP -セッション開始プロトコルl

SSL -Secure Sockets Layer

TCP -伝送制御プロトコル

UDP -ユーザーデータグラムプロトコル

UPnP -ユニバーサルプラグアンドプレイ

WB -ホワイトボード (共有)

ページのトップへ

トピック

はじめに

NAT とファイアウォールの問題点

NAT と Windows Messenger

NAT デバイスを原因とする問題

さまざまな NAT デバイス設定での動作

ファイアウォールと Windows Messenger

さまざまなファイアウォール設定での動作

Windows XP の UPnP の限界

Windows Messenger の設定 : 動作する場合と動作しない場合

動作する設定

動作しない設定

ソリューション

NAT デバイス

ファイアウォール デバイス

Microsoft Internet Security and Acceleration (ISA) サーバーのオーディオとビデオ

シナリオ

まとめ

略語集

関連リンク

ダウンロード

ファイアウォールデバイス