| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
以下の節では、ネットワーク リソースを Oracle WebLogic Communication Services で使用するためにコンフィグレーションする方法について説明します。
Oracle WebLogic Communication Services の各インスタンスのデフォルトの HTTP ネットワーク コンフィグレーションは、各サーバのリスン アドレスおよびリスン ポートの設定に基づいて決定されます。ただし、Oracle WebLogic Communication Services では HTTP 上の SIP プロトコルはサポートされていません。SIP プロトコルは、UDP および TCP 転送プロトコル上でサポートされています。また、転送プロトコルとして TLS を使用する SIPS もサポートされています。
UDP、TCP、または TLS による転送を有効にするには、Oracle WebLogic Communication Services instance のインスタンスに対して 1 つまたは複数の「ネットワーク チャネル」をコンフィグレーションします。 ネットワーク チャネルは、そのサーバ インスタンスに対する特定のネットワーク接続の属性を定義するコンフィグレーション可能な WebLogic Server リソースです。基本的なチャネルの属性は次のとおりです。
接続でサポートされているプロトコル
接続で使用されるポート番号
発信される UDP パケットで使用されるポート番号 (省略可能)
チャネルを発信接続に使用する場合に SIP ヘッダに埋め込まれるパブリック リスン アドレス (ロード バランサのアドレス)
Oracle WebLogic Communication Services の 1 つのインスタンスに複数のチャネルを割り当てて、複数のプロトコルをサポートすることや、マルチホームのサーバ ハードウェアに搭載されている複数のインタフェースを利用することができます。同一のチャネルを複数のサーバ インスタンスに割り当てることはできません。
SIP プロトコル用の新しいネットワーク チャネルをコンフィグレーションすると、UDP および TCP 転送プロトコルの両方が指定されたポートで有効です。UDP または TCP のどちらか一方の転送プロトコルのみを使用する SIP チャネルを作成することはできません。SIPS プロトコル用のネットワーク チャネルをコンフィグレーションすると、そのチャネルの接続では、転送プロトコルとして TLS が使用されます。
新しい SIP Server ドメインをコンフィグレーションする場合は、通常、システム内のエンジン層の各サーバとの通信に使用する複数の SIP チャネルを作成する必要があります。エンジン層のサーバは、レプリカ用にコンフィグレーションされたリスン アドレス属性を使用して、SIP データ層のレプリカと通信できます。ただし、レプリカ間で相互に通信するには、レプリカで一意なリスン アドレスを使用する必要があります。
|
注意 : SIP データ層のクラスタで複数のレプリカをコンフィグレーションする場合は、サーバごとに一意なリスン アドレス (一意な DNS 名または IP アドレス) をコンフィグレーションする必要があります。一意なリスン アドレスを指定しない場合は、デフォルトの localhost アドレスにレプリカ サービスがバインドされるため、複数のレプリカがお互いを見つけることができなくなります。 |
オペレーティング システムとハードウェア が IPv6 をサポートしている場合は、は、ネットワーク通信に IPｖ6 を使用できるように Oracle WebLogic Communication Services をコンフィグレーションできます。SIP トラフィックの IPv6 は、IPv6 アドレスでネットワーク チャネルをコンフィグレーションすると有効になります。IPv6 SIP チャネルは、IPv6 トラフィックをサポートする各エンジン層サーバでコンフィグレーションする必要があります。詳細については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。
エンジン上でコンフィグレーションした各 SIP ネットワーク チャネルは、IPv6 または IPv4 トラフィックをサポートします。1 つのチャネルで IPv4 と IPv6 トラフィックをいっしょに使用することはできません。1 つのエンジンは、複数の個別のネットワークをサポートするために、IPv4 と IPv6 チャネルの両方でコンフィグレーションすることができます。
Oracle WebLogic Communication Services のエンジンおよび SIP データ層ノードは、外部 SIP トラフィックのために他のプロトコル バージョンをサポートしながら、IPv4 (または IPv6) で通信することもできます。IPv6 ネットワークでエンジンおよび SIP データ層ノードをコンフィグレーションするには、各サーバ インスタンスに対して IPv6 リスン アドレスを指定します。
IPv 4 と IPv6 ネットワーク チャネルのコンフィグレーションの詳細については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。
エンジン層への接続を分散するためにシステムで 1 つまたは複数のロード バランサを使用する場合は、SIP ネットワーク チャネルのコンフィグレーションにおいて、ロード バランサのアドレスを「外部リスン アドレス」として設定する必要があります。 SIP チャネルの外部リスン アドレスがそのチャネルのプライマリ リスン アドレスと異なる場合は、外部リスン アドレスのホストとポート番号が Response などの SIP ヘッダに Oracle WebLogic Communication Services によって埋め込まれます。そのため、その呼に関するそれ以後の通信では外部からの送信先としてロード バランサのパブリック アドレスが使用され、ローカルのエンジン層サーバのアドレスは指定されません (外部クライアントからはエンジン層サーバのアドレスにアクセスできない場合もあります)。
ネットワーク チャネルにおいて外部リスン アドレスがコンフィグレーションされていない場合は、そのチャネルのプライマリ リスン アドレスが SIP ヘッダに埋め込まれます。
システムで 2 つのロード バランサを使用する場合は、エンジン層の各サーバにおいて 2 つのチャネル (それぞれのロード バランサへのネットワーク接続につき 1 つずつ) を定義し、それぞれのロード バランサに外部リスン アドレスを割り当てる必要があります。エンジン層サーバ上の特定のネットワーク インタフェースが発信トラフィック用のインタフェースとして選択されているときは、そのネットワーク インタフェース カード (NIC) のアドレスに関連付けられているネットワーク チャネルに基づいて、SIP ヘッダに埋め込む外部リスン アドレスが決定されます。
2 つのパブリック アドレスを持つマルチホームのロード バランサを使用する場合も、同様に 2 つのチャネルを定義して、その両方のパブリック アドレスをコンフィグレーションする必要があります。エンジン層サーバに搭載されている NIC が 1 つのみのときは、ロード バランサの 2 番目のパブリック アドレス専用のチャネルをコンフィグレーションするために、その NIC の 2 番目のアドレスを論理アドレスとして定義しなければなりません。さらに、IP ルーティング ポリシーをコンフィグレーションして、ロード バランサのそれぞれのパブリック アドレスにどの論理アドレスを関連付けるかを指定することも必要です。
Oracle WebLogic Communication Services は、SIP メッセージを送信するのに必要なプロキシ転送、IP アドレスおよびポート番号を解決するマルチホームをサポートしています。これは、RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt) に説明されている動作に一致しています。 また、マルチホームは宛先の IP アドレスおよびポート番号を解決するために応答をルーティングするときにも使用できます。
|
注意 : マルチホーム解決は SIP メッセージ処理のコンテクスト内で実行されるため、どのようなマルチホーム パフォーマンス問題でもレイテンシ増加の原因となります。潜在的なパフォーマンス問題を削減するためにプロダクション環境ではキャッシング マルチホーム サーバを使用することをお勧めします。 |
マルチホーム サポートのコンフィグレーション手順
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
コンソールの左ペインの [SipServer] ノードを選択します。
右ペインの [コンフィグレーション｜一般] タブを選択します。
[マルチホーム サーバ ルックアップを有効化] を選択します。
[保存] をクリックして変更内容を保存します。
マルチホーム ルックアップを有効にすると、サーバは以下の目的でマルチホームを使用できます。
SIP URI にリクエストを送信する場合、プロキシ サーバ転送、IP アドレスとポート番号を検出します。
[Sent-by] フィールドの内容に基づいて、応答のルーティングの際に IP アドレスとポート番号を解決します。
プロキシ検出のために Oracle WebLogic Communication Services は、SIP トランザクション毎に一度マルチホーム解決を使用して転送、IP とポート番号に関する情報を決定します。すべての再送信、ACKs または CANCEL リクエストは同じ転送を使用して同じアドレスとポートに配信されます。マルチホーム解決をどのように実行するかについての詳細については、RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt) を参照してください。
プロキシが応答メッセージの送信を要求されている場合、Oracle WebLogic Communication Services は sent-by フィールドとヘッダで提供された情報によっては送信先の IP アドレスおよびポート番号を決定するためマルチホーム ルックアップを使用します。
コンフィグレーション ウィザードを使用して新しいドメインを作成すると、Oracle WebLogic Communication Services のインスタンスは、UDP または TCP 上の SIP プロトコルをサポートするデフォルトのネットワーク チャネルを使用するようにコンフィグレーションされます。デフォルト チャネルではリスン ポートとして 5060 が設定されていますが、リスン アドレスは指定されていません。デフォルト チャネルのリスン アドレスまたはリスン ポートの設定を変更するには、節 4.4.1「既存チャネルの再コンフィグレーション」の手順に従ってください。 デフォルト以外のプロトコルやネットワーク インタフェースを追加的にサポートするために新しいチャネル リソースを作成する手順については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。
既存チャネルでサポートされているプロトコルを変更することはできません。既存のリスン アドレスとリスン ポートの組み合わせを再コンフィグレーションして、別のネットワーク プロトコルを使用するように変更するには、その既存チャネルを削除した上で、節 4.4.2「新しい SIP または SIPS チャネルの作成」の手順に従って新しいチャネルを作成する必要があります。
チャネルをコンフィグレーションするには :
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
左ペインで、[環境｜サーバ] タブを選択します。
右ペインで、コンフィグレーションするサーバの名前を選択します。
[プロトコル｜チャネル] タブを選択して、コンフィグレーション済みのチャネルを表示します。
既存チャネルを削除するには、表から選択して、[Delete] をクリックします。
既存チャネルを再コンフィグレーションするには、以下の手順を実行します。
チャネル リストからチャネル名 (たとえば、デフォルトの sip チャネル) を選択します。
[リスン アドレス] フィールドまたは [リスン ポート] フィールドを編集して、関連付けられているエンジン層マシン上の NIC のアドレスまたは論理アドレスに一致するように変更します。
|
注意 : リスン アドレスとリスン ポートを変更する前に、チャネルを無効にする必要があります。 |
[外部リスン アドレス] フィールドまたは [外部リスン ポート] フィールドを編集して、システムのロード バランサのパブリック アドレスに一致するように変更します。
必要に応じて、高度なチャネル属性を編集します (詳細については、節 4.4.2「新しい SIP または SIPS チャネルの作成」を参照してください。)
[保存] をクリックします。
SIP または SIPS の新規チャネルを Oracle WebLogic Communication Services インスタンスのコンフィグレーションに作成するには、以下の手順を実行します。
コンフィグレーションする Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
左ペインで、[環境｜サーバ] タブを選択します。
右ペインで、コンフィグレーションするサーバの名前を選択します。
[プロトコル｜チャネル] タブを選択して、コンフィグレーション済みのチャネルを表示します。
[New] をクリックして、新しいチャネルをコンフィグレーションします。
新規チャネルの各フィールドの値を以下のように指定します。
[名前] : このチャネルに付ける管理用の名前 (たとえば SIPS-Channel-eth0) を入力します。
[プロトコル] : UDP および TCP による転送をサポートする SIP、または TLS による転送をサポートする SIPS のいずれかを選択します。 SIP チャネルでは、コンフィグレーションされたポート上で UDP または TCP のどちらか一方のみによる転送をサポートすることはできません。
[次へ] をクリックします。
新規チャネルのアドレス指定フィールドの値を以下のように指定します。
[リスン アドレス] : このチャネルの IP アドレスまたはマルチホーム名を入力します。マルチホーム マシンの場合は、コンフィグレーション対象のインタフェースの正確な IP アドレス、またはその正確な IP アドレスにマッピングされているマルチホーム名を入力します。
[リスン ポート] : このチャネルを介した通信に使用するポート番号を入力します。[リスン アドレス] と [リスン ポート] の組み合わせは、そのサーバでコンフィグレーションされている他のどのチャネルの設定とも異なる必要があります。SIP チャネルでは、コンフィグレーションされたポート上で UDP および TCP の両方の転送がサポートされます。
[外部リスン アドレス] および [外部リスン ポート] : このチャネルに関連付けられているロード バランサのパブリック アドレスに一致するように編集します。Oracle WebLogic Communication Services は、発信ネットワーク トラフィックに使用するインタフェースまたは論理アドレスを選択するときに、同じプライマリ 「リスン アドレス」を使用するようにコンフィグレーションされているチャネルを調べます。そのチャネルの「外部リスン アドレス」が異なる場合は、その外部リスン アドレスが SIP メッセージ ヘッダに埋め込まれて、それ以後のコール トラフィックで使用されるようになります。節 4.2「ロード バランサのアドレスのコンフィグレーション」を参照してください。
[次へ] をクリックします。
必要があれば、[表示] をクリックして高度なチャネル プロパティを表示し、「接続のタイムアウト」値などの各種プロパティを編集します。 高度なチャネル プロパティについては、以下の制限や推奨事項に留意してください。
[発信の有効化] - SIP および SIPS のすべてのチャネルはネットワーク接続の発信元になる可能性があるので、この属性のチェックをはずすことはできません。
[このプロトコルで HTTP を有効化] - Oracle WebLogic Communication Services では、転送に HTTP を使用する SIP プロトコルはサポートされていないので、SIP および SIPS のチャネルでこの属性を選択することはできません。
[最大メッセージ サイズ] - この属性は、このチャネルを発信元とする通信で使用可能な TCP メッセージの最大サイズを指定します。メッセージのサイズがこの属性でコンフィグレーションされている最大サイズを超えている通信は、Oracle WebLogic Communication Services によってすべて切断されます。デフォルトのサイズは 10,000,000 バイトです。このデフォルトのサイズはかなり大きいので、サーバへのサービス拒否 (DOS) 攻撃に対する防御を重視する場合は、デプロイされているサービスに支障のない範囲でこの属性の値をより小さい値に変更してください。
[Finish] をクリックします。
SIP チャネルは 1 つ以上のカスタム チャネル プロパティを使用してさらにコンフィグレーションすることができます。カスタム プロパティは Administration Console を使用して設定することはできません。その代わりに、ドメインに対して、config.xml ファイルのチャネル コンフィグレーションの一部にある単一の custom-property スタンザへプロパティを追加するためにテキスト エディタを使用する必要があります。
Oracle WebLogic Communication Services には、SIP チャネルの転送プロトコルに影響する次のカスタムプロパティがあります。
TcpConnectTimeoutMillis - Oracle WebLogic Communication Services が送り先アドレス (発信 TCP 接続) をアクセス不能として宣言する前に、その待機時間を指定します。 このプロパティは SIP チャネルのみに適用されます。Oracle WebLogic Communication Services では、SIPS チャネルのこの属性の値が無視されます。値が 0 の場合、タイムアウトが完全に無効になります。 カスタム プロパティを指定しない場合、デフォルトとして 3000 ミリ秒が使用されます。
SctpConnectTimeoutMillis - Oracle WebLogic Communication Services が送り先アドレス ( 発信 SCTP 接続 ) をアクセス不能として宣言する前に、その待機時間を指定します。 プロパティは SCPT チャネルのみに適用されます （Diameter トラフィック用）。値が 0 の場合、タイムアウトが完全に無効になります。カスタム プロパティを指定しない場合、デフォルトとして 3000 ミリ秒が使用されます。Diameter の SCTP チャネルを作成する情報については、節 4.8.1.1「発信 UDP パケット用の静的ポートのコンフィグレーション」を参照してください。
SourcePorts - UDP パケットを作成するためにサーバが使用する 1 つまたは複数の静的ポート番号をコンフィグレーションします。
|
警告 : SourcePorts カスタム プロパティを使用するとパフォーマンスが低下するので、ほとんどのコンフィグレーションでは、このプロパティを使用することは望ましくありません。UDP パケットを作成するために Oracle WebLogic Communication Services が使用する正確なポート数を指定する必要がある場合にのみ、このプロパティをコンフィグレーションします。 |
Mtu - このチャネルの最大転送ユニット (MTU) 値を指定します。-1 の値を指定すると、転送のためにデフォルトの MTU が使用されます。
EnabledProtocolVersions - Oracle WebLogic Communication Services が SSL クライントとして動作する場合、このチャネルに使用する SSL プロトコルのバージョンを指定します。 SSL クライントとして動作する場合、チャネルではサポート対象のプロトコルとして TLS V1.0 のバージョンを必要とします。SSL V3.0 が SSL のピアー サーバのサポート対象バージョンのうち最も高バージョンであれば、そのバージョンを使用するようにサーバをコンフィグレーションできます。このプロパティには次のいずれかの値を設定することができます。
デフォルトの TLS1 に設定すると、TLS V1.0 メッセージのみを送受信するようにチャネルがコンフィグレーションされます。ピアは TLS V1.0 メッセージに応答する必要があります。応答しない場合は、SSL 接続が切断されます。
SSL3 に設定すると、チャネルが SSL V3.0 メッセージのみを送受信するようにコンフィグレーションされます。ピアは SSL V3.0 メッセージに応答する必要があります。応答しない場合は、SSL 接続が切断されます。
ALL に設定すると、TLS V1.0 か SSL V3.0 メッセージをサポートします。ピアは TLS V1.0 か SSL V3.0 に応答する必要があります。応答しない場合は、SSL 接続が切断されます。
カスタム プロパティをコンフィグレーションする場合、テキスト エディタを使用して [config.xml] ファイルを直接変更するか、WLST などの JMX クライアントを使用してカスタム プロパティを追加します。[config.xml] ファイルを直接編集する場合、チャネルのコンフィグレーション スタンザの末尾に追加するカスタム-プロパティの要素は 1 つだけにしてください。例 4-1 に示すように、セミコロン (;) を使用して同一要素内の複数のカスタム プロパティを区切ります。
例 4-1 カスタム プロパティの設定
<network-access-point>
<name>sip</name>
<protocol>sip</protocol>
<listen-port>5060</listen-port>
<public-port>5060</public-port>
<http-enabled-for-this-protocol>false</http-enabled-for-this-protocol>
<tunneling-enabled>false</tunneling-enabled>
<outbound-enabled>true</outbound-enabled>
<enabled>true</enabled>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<client-certificate-enforced>false</client-certificate-enforced>
<custom-properties>EnabledProtocolVersions=ALL;Mtu=1000;SourcePorts=5060</custom-properties>
</network-access-point>
複数のネットワーク インタフェースを持つサーバ (「マルチホーム」サーバ) をコンフィグレーションする場合は、Oracle WebLogic Communication Services で使用する各 IP アドレスのネットワーク チャネルを個別にコンフィグレーションする必要があります。 Oracle WebLogic Communication Services では、SIP メッセージのシステム ヘッダにルーティング情報を埋め込む際に、各チャネルのリスン アドレスおよびリスン ポートの値が使用されます。
|
注意 : マルチホーム マシン上に、チャネルがコンフィグレーションされていない IP アドレスがある場合、その IP アドレスを Via、Contact、および Record-Route ヘッダの値として設定することはできません。 |
Oracle WebLogic Communication Services の Diameter 実装では、TCP または TLS 転送プロトコル上の Diameter プロトコルがサポートされています。サーバに対する着信 Diameter 接続を有効にするには、専用のネットワーク チャネルをコンフィグレーションします。転送プロトコルとして TCP を使用する場合は diameter のプロトコル タイプを選択し、TCP および TLS を使用する場合は diameters を選択します。 Diameter 仕様 (RFC 3558) に記述されているように、Diameter 実装アプリケーションは、TLS を使用するために Diameter 接続を自動的にアップグレードする場合があります。
Diameter プロトコルをサポートするためのネットワーク チャネルのコンフィグレーションの詳細については、第 10 章「Diameter クライアント ノードとリレー エージェントのコンフィグレーション」を参照してください。
Oracle WebLogic Communication Services をコンフィグレーションして、使用可能な任意の IP インタフェース上で UDP トラフィックをリスンするには、新しい SIP チャネルを作成して、リスン アドレスとして 0.0.0.0 (または、IPv6 ネットワークには :: ) を指定します。ただし、その場合でも、SIP メッセージの発信用のチャネルとして、IP アドレスが明示的に指定されたチャネルを少なくとも 1 つはコンフィグレーションする必要があります。(マルチホーム マシンでは、メッセージの発信に使用する各インタフェースに対して個別にチャネルをコンフィグレーションする必要があります)。
|
注意 : 0.0.0.0 コンフィグレーションの使用は、Linux プラットフォームの UDP トラフィックにのみ影響します。Oracle WebLogic Communication Services では、サーバのコンフィグレーションされたホスト名とローカル ホストに対応する TCP および HTTP リスン スレッドのみが作成されます。ホスト名に複数のアドレスをマップする場合は、Oracle WebLogic Communication Services の起動時に警告メッセージが表示されます。この問題を回避してすべてのアドレスでリスンするには、HTTP と TCP トラフィックに対して IPｖ6 と IPv4 両方で使用可能なすべてのアドレスを含む :: アドレスを指定します。 |
SIP データ層のレプリカがピアとして相互に通信できるようにするには、一意なリスン アドレス属性 (一意なマルチホーム名または IP アドレス) を各レプリカにバインドする必要があります。各レプリカに一意なリスン アドレスを割り当てるには、以下の手順を実行します。
Oracle WebLogic Communication Services ドメインの Administration Console にアクセスします。
左ペインで、[環境｜サーバ] を選択します。
右ペインで、コンフィグレーションするサーバの名前を選択します。
[コンフィグレーション｜一般] タブを選択します。
一意な DNS 名または IP アドレスを [リスン アドレス] フィールドに入力します。
[保存] をクリックします。
プロダクション環境 (エンタープライズ デプロイメント) にインストールされている Oracle WebLogic Communication Services は、ほとんどの場合、以下の特徴を 1 つ以上備えています。
複数のエンジン層サーバによってクラスタが構成されています。
エンジン層の各サーバ インスタンスが複数のネットワーク チャネルを持ち、複数の SIP 転送プロトコル、またはマルチホーム ハードウェア上の複数のネットワーク インタフェース カード (NIC) がサポートされています。
システムに 1 つまたは複数のロード バランサ、またはマルチホームのロード バランサが含まれているため、サーバのフェイルオーバが可能になっており、必要に応じて、ネットワーク パケットの送信元または送信先のアドレスを書き換えるネットワーク アドレス変換 (NAT) を実行できます。
このような各種のネットワーク要素が組み合わされて使用されていると、各要素が互いにどのように作用し合い、ネットワーク要素やコンフィグレーション オプションの特定の組み合わせが SIP メッセージまたは転送プロトコル データグラムの内容にどのような影響を与えるのかが理解しにくくなる場合があります。
以下の節では、Oracle WebLogic Communication Services の一般的なネットワーク アーキテクチャについて解説し、各アーキテクチャでサーバをコンフィグレーションする方法を説明します。また、SIP メッセージおよび転送データグラム内の情報が各コンフィグレーションによってどのような影響を受けるかについても説明します。図 4-1 は、OSI (Open Systems Interconnect) の典型的なモデルにおいて、さまざまなネットワーク コンフィグレーションの影響を受ける可能性があるレイヤを示したものです。
図 4-1 Oracle WebLogic Communication Services のネットワーク コンフィグレーションの影響を受ける OSI レイヤ
レイヤ 3 (ネットワーク層) およびレイヤ 4 (トランスポート層) には、発信および受信される転送データグラムの送信元または送信先 IP アドレスとポート番号が格納されています。SIP プロトコルでは、SIP メッセージの送信元にアクセスするためのアドレス情報を特定の SIP ヘッダ内に記述するように規定されているので、レイヤ 7 (アプリケーション層) も影響を受ける可能性があります。
NIC が 1 枚だけ搭載されたサーバを使用する単純なネットワーク コンフィグレーションでは、1 つまたは複数のネットワーク チャネルを作成して、UDP および TCP 上の SIP メッセージ、または TLS 上の SIPS メッセージをサポートすることができます。この単純なコンフィグレーションが OSI モデルの情報にどのように影響するかを理解しておくと、マルチホーム ハードウェアおよびロード バランサを使用したさらに複雑なコンフィグレーションが、同じ情報にどのような影響を与えるのかが理解できます。
図 4-2 は、単一の NIC を持つ 1 つのエンジン層サーバのインスタンスを示したものです。 このサーバでは、UDP および TCP 上の SIP をサポートする 1 つのネットワーク チャネルがコンフィグレーションされています。(SIP チャネルは、常に UDP 転送と TCP 転送の 2 つともサポートします。2 つのうち一方のみをサポートすることはできません)。図 4-2 では、サーバと 2 つのクライアントが 1 つは UDP もう 1 つは TCP を使用して通信していることを示します。
TCP による転送の場合、発信データグラム (Oracle WebLogic Communication Services からユーザ エージェントに送信されるデータグラム) には次の情報が含まれています。
レイヤ 3 には、そのネットワーク チャネルで指定されている送信元 IP アドレス (上記例では 10.1.1.10) が含まれています。
レイヤ 4 には、基盤のオペレーティング システムによって割り当てられた送信元ポート番号が含まれています。
TCP の受信データグラム (ユーザ エージェントから Oracle WebLogic Communication Services に送信されるデータグラム) には次の情報が含まれています。
レイヤ 3 には、そのネットワーク チャネルで指定されている送信先 IP アドレス (10.1.1.10) が含まれています。
レイヤ 4 には、そのネットワーク チャネルで指定されている送信先ポート番号 (5060) が含まれています。
UDP の発信データグラムの場合、OSI レイヤの情報には TCP による転送の場合と同じ情報が含まれています。UDP の受信データグラムの場合、OSI レイヤの情報は、受信データグラムのレイヤ 4 の情報以外は TCP の場合と同じです。UDP の受信データグラムのレイヤ 4 には、次のどちらかが含まれています。
そのネットワーク チャネルで指定されている送信先ポート番号 (5060)
Oracle WebLogic Communication Services によって事前に割り当てられたエフェメラル ポート番号
デフォルトの場合、Oracle WebLogic Communication Services では、基盤のオペレーティング システムにおいて UDP 発信データグラムのエフェメラル ポート用に確保されているポート番号範囲からポート番号が割り当てられます。Oracle WebLogic Communication Services では、外部からの接続において、ネットワーク チャネルでコンフィグレーションされているポート番号のほかに、任意のエフェメラル ポイントを送信先ポート番号として使用できます。つまり、Oracle WebLogic Communication Services では、サーバによって割り当てられたすべてのエフェメラル ポートで自動的にリスンが行われます。Oracle WebLogic Communication Services でのエフェメラル ポート番号の使用は、必要に応じて無効にできます。エフェメラル ポート番号が使用されないようにするには、サーバの起動時に次のオプションを指定します。
-Dwlss.udp.listen.on.ephemeral=false
Oracle WebLogic Communication Services で特定のエフェメラル ポートが使用されているかどうかを確かめるには、サーバのログ ファイルに記録されている次のような情報を調べて、使用されているポート番号を確認してください。
<Nov 30, 2005 12:00:00 AM PDT> <Notice> <WebLogicServer> <BEA-000202> <Thread "SIP Message Processor (Transport UDP)" listening on port 35993.>
Oracle WebLogic Communication Services のネットワーク チャネルでは、SourcePorts 属性を使用することにより、サーバから UDP パケットを発信するために使用する 1 つまたは複数の静的ポートをコンフィグレーションできます。
|
警告 : SourcePorts カスタム プロパティを使用するとパフォーマンスが低下するので、ほとんどのコンフィグレーションでは、このプロパティを使用することは望ましくありません。UDP パケットを作成するために Oracle WebLogic Communication Services が使用する正確なポート数を指定する必要がある場合にのみ、このプロパティをコンフィグレーションします。 |
SourcePorts プロパティをコンフィグレーションする場合、WLST などの JMX クライアントを使用するか、config.xml ファイルのネットワーク チャネルのコンフィグレーションを直接変更してカスタム プロパティを追加します。SourcePorts には、ポート番号またはポート番号範囲の配列を指定します。SourcePorts の定義内ではスペースを使用しないでください。ポートの範囲を示すには、ポート番号、ハイフン (「-」) を使用し、範囲や各ポートを区切るにはカンマ (「,」) を使用します。コンフィグレーションの記述例については、例 4-2 を参照してください。
例 4-2 発信 UDP パケットの静的ポート コンフィグレーション
<network-access-point> <name>sip</name> <protocol>sip</protocol> <listen-port>5060</listen-port> <public-port>5060</public-port> <http-enabled-for-this-protocol>false</http-enabled-for-this-protocol> <tunneling-enabled>false</tunneling-enabled> <outbound-enabled>true</outbound-enabled> <enabled>true</enabled> <two-way-ssl-enabled>false</two-way-ssl-enabled> <client-certificate-enforced>false</client-certificate-enforced> <custom-properties>SourcePorts=5060</custom-properties> </network-access-point>
プロダクション デプロイメントのエンジン層サーバでは、多くの場合、複数の NIC が搭載されたマルチホームのサーバ ハードウェアが利用されます。マルチホーム ハードウェアは、一般に、次のどちらかの目的で使用されます。
同一のサブネット内での冗長なネットワーク接続の実現。複数の NIC を使用すると、いずれか 1 つの NIC に障害が発生した場合でも、それ以外の 1 つまたは複数のネットワーク接続を使用して、データ層サーバまたは管理サーバと通信することができます。
複数の異なるサブネット間の SIP 通信のサポート。たとえば、異なるサブネット上のユーザ エージェント (UA) が相互に直接通信できない場合は、Oracle WebLogic Communication Services をコンフィグレーションして、1 つのサブネットの UA から別のサブネットの UA に SIP リクエストを送信するためのプロキシとして機能させることができます。
コンフィグレーションの要件および OSI レイヤの情報は、システムでマルチホーム ハードウェアを使用する目的によって異なります。1 つのサブネット内で冗長なネットワーク接続を実現することを目的として複数の NIC を使用する場合は、通常、節 4.8.3「すべてのアドレス (IP_ANY) でリスンするマルチホーム サーバ」で説明している方法により、使用可能なすべてのアドレス (IP_ANY) でリスンするようにサーバをコンフィグレーションします。
複数の異なるサブネットをサポートすることを目的として複数の NIC を使用する場合は、節 4.8.4「複数のサブネットでリスンするマルチホーム サーバ」で説明しているように、サーバ上で複数のネットワークをそれぞれの異なる NIC に対してコンフィグレーションする必要があります。
最も単純なマルチホーム コンフィグレーションを使用すると、利用可能なすべての NIC (物理 NIC および論理 NIC) において、Oracle WebLogic Communication Services の 1 つのインスタンスによるリスンを実行できるようになります。このコンフィグレーションは IP_ANY と呼ばれることもあります。これを実現するために必要なのは、1 つのネットワーク チャネルをコンフィグレーションして、チャネルのリスン アドレスとして 0.0.0.0 を指定することだけです。
0.0.0.0 のアドレスは、そのサーバのネットワーク チャネル上で直接コンフィグレーションする必要があります。チャネルの IP アドレスを指定しないと、サーバ インスタンス自体にコンフィグレーションされているリスン アドレスがチャネルに継承されます。節 4.6「エンジン サーバで任意の IP インタフェースでリスンする場合のコンフィグレーション」を参照してください。
複数の NIC は、複数のサブネット上でリスンするためにエンジン層サーバで使用することもできます。その場合の最も一般的なコンフィグレーションでは、直接的な相互アクセスが許可されていない複数のサブネット間の通信を実現するために、Oracle WebLogic Communication Services が SIP トラフィックのプロキシとして使用されます。図 4-3 は、このコンフィグレーションを示します。
Oracle WebLogic Communication Services インスタンスを図 4-3 にコンフィグレーションするため、サーバ マシン上で使用した各 NIC にネットワーク チャネルを定義する必要があります。 例 4-3 は、サンプル コンフィグレーションのチャネルを定義する config.xml エントリを示します。
例 4-3 複数のサブネット上の各 NIC で使用するネットワーク チャネル コンフィグレーションのサンプル
<NetworkAccessPoint ListenAddress="10.1.1.10" ListenPort="5060" Name="sipchannelA" Protocol="sip"/> <NetworkAccessPoint ListenAddress="10.2.1.10" ListenPort="5060" Name="sipchannelB" Protocol="sip"/>
Oracle WebLogic Communication Services が複数のサブネットでリスンするようにコンフィグレーションされている場合は、route resolver と呼ばれる機能によって、次の処理が行われます。
OSI レイヤ 7 情報内に (Via、Contact などの SIP システム ヘッダに)、正しいアドレスが格納されます。
OSI レイヤ 3 情報内に、正しい送信元 IP アドレスが格納されます。
たとえば、図 4-3 に示したコンフィグレーションの場合、各 UA が SIP トランザクションの処理を続行できるようにするには、Oracle WebLogic Communication Services において、正しいサブネット アドレスを SIP システム ヘッダと転送データグラムに追加する必要があります。 不適切なサブネット アドレスが使用されると、どちらの UA も別の UA のサブネットに直接アクセスできないので、応答を配信できなくなります。
ルート リゾルバは、オペレーティング システムが特定の送信先にデータグラムを送信する際に使用する NIC を判別して、その NIC に関連付けられているネットワーク チャネルを調査します。そして、選択されたそのネットワーク チャネルでコンフィグレーションされているアドレスの情報を、SIP ヘッダおよびレイヤ 3 のアドレス情報として格納します。
たとえば、図 4-3 に示すコンフィグレーションでは、Oracle WebLogic Communication Services から UAC B に送信された INVITE メッセージの送り先のアドレスは 10.2.1.16 です。このメッセージは対応するサブネットにコンフィグレーションされた NIC B を使用して送信されます。 ルート リゾルバは、コンフィグレーション済みの sipchannelB に NIC B を関連付け、そのチャネルの IP アドレス (10.2.1.10) を SIP メッセージの VIA ヘッダに埋め込みます。そのため、そのメッセージを受け取った UAC B では、VIA ヘッダの値に基づいて、それ以後のメッセージをサーバの正しい IP アドレスに向けて送信できるようになります。UAC A でも同様の処理が行われるので、適切なサブネット以外にメッセージが配信されることはありません。
IP エリアスを使用すると、1 つの NIC に複数の論理 IP アドレスを割り当てることができます。IP エリアスのコンフィグレーションは、サーバの基盤のオペレーティング システムで行われます。すべての論理アドレスが同一サブネット内のアドレスであるように IP エリアスをコンフィグレーションする場合は、節 4.8.3「すべてのアドレス (IP_ANY) でリスンするマルチホーム サーバ」で説明したように、すべてのアドレスでリスンするように Oracle WebLogic Communication Services を簡単にコンフィグレーションできます。
IP エリアスをコンフィグレーションして、異なるサブネット上の複数の論理 IP アドレスを作成する場合は、それぞれの論理アドレスのネットワーク チャネルを個別にコンフィグレーションする必要があります。このコンフィグレーションにおいて、Oracle WebLogic Communication Services ではすべての論理アドレスが別々の物理インタフェース (NIC) として扱われ、ルート リゾルバの機能により、各インタフェースでコンフィグレーションされているチャネルの情報に基づいて OSI レイヤ 4 およびレイヤ 7 に情報が格納されます。
ロード バランサは、複数のサーバ間でのフェイルオーバ機能やクライアントからの負荷の分散を実現するだけでなく、クライアントとサーバの間で送受信されるネットワーク情報をコンフィグレーションするためのツールとしても重要です。以下の節では、Oracle WebLogic Communication Services で使用される一般的なロード バランサのコンフィグレーションについて説明します。
最も一般的なロード バランサのコンフィグレーションでは、図 4-4 に示したように、単一のロード バランサを使用して、エンジン層サーバのクラスタにアクセスするためのゲートとして利用します。
Oracle WebLogic Communication Services をコンフィグレーションして図 4-4 のように単一のロード バランサを使用するには、各サーバで 1 つまたは複数のネットワーク チャネルをコンフィグレーションした上で、ロード バランサの仮想 IP アドレスを使用するように各チャネルのパブリック アドレスをコンフィグレーションします。 このコンフィグレーションでは、その後の返信の クラスタにクライアントが確実に到達できるよう、Oracle WebLogic Communication Services は SIP メッセージ システム ヘッダにロード バランサ IP アドレスを組み込みます。第 4 章「ネットワーク リソースの管理」はロード バランサ アドレスに対してコンフィグレーション ネットワーク チャネルの詳細なステップを示します。
|
注意 : ロード バランサとして使用されるスイッチの一部は、1 つの呼び出しのすべての SIP メッセージが同一のエンジン層サーバに送信されるように自動的に再ルーティングする機能を備えていますが、Oracle WebLogic Communication Services のロード バランサとして使用する場合は、この機能は必須ではありません。詳細については、節 15.7「他のコンフィグレーション」を参照してください。 |
複数のロード バランサ (またはマルチホームのロード バランサ) をコンフィグレーションすると、Oracle WebLogic Communication Services の 1 つのクラスタに複数の仮想 IP アドレスを割り当てることができます。マルチホームのロード バランサを使用できるように Oracle WebLogic Communication Services をコンフィグレーションするには、各ロード バランサまたはローカル サーバの各 NIC に個別に専用のネットワーク チャネルを作成した上で、そのチャネルのパブリック アドレスとして、適切なロード バランサの仮想 IP アドレスを設定します。このコンフィグレーションでは、コンフィグレーションされたチャネルと、SIP メッセージの発信に使用される NIC との関連付けがルート リゾルバによって行われます。そして、選択されたチャネルのパブリック アドレスは、SIP システム メッセージ内にアドレス情報として格納されます。節 4.8.4.1「ルート リゾルバについて」を参照してください。
最も一般的な場合は、クライアントがパブリック IP アドレスを使用して Oracle WebLogic Communication Services の 1 つまたは複数の内部 (プライベート) アドレスと通信できるように、ロード バランサは送信先 NAT を使用するようにコンフィグレーションされます。ロード バランサでは、送信元 NAT を使用するようにコンフィグレーションして、プライベート アドレスから発信されるパケットのレイヤ 3 アドレス情報をロード バランサ自体の仮想 IP アドレスに一致するように変更することもできます。
ルート リゾルバがデフォルトの状態で動作している場合、Oracle WebLogic Communication Services エンジンから発信される UDP パケットの送信元 IP アドレスは、ローカル NIC のアドレス (プライベート アドレス) と一致します。外部からはローカル サーバのアドレスにアクセスできない場合があるので、このように発信元のアドレスとしてローカル アドレスが使用されていると、転送パケットに埋め込まれているレイヤ 3 のアドレスに直接応答しようとするアプリケーションにおいて問題が発生するおそれがあります。使用しているアプリケーションでこの問題が発生する場合は、転送レイヤ 3 のアドレスを外部からアクセス可能な仮想 IP アドレスに変更するために、ロード バランサで送信元 NAT を実行するようにコンフィグレーションすることをお勧めします。
Oracle WebLogic Communication Services では、ロード バランサでの送信元 NAT を有効にしない場合は、限定的な IP マスカレード機能を使用できます。この機能を使用するには、クラスタのロード バランサのパブリック IP アドレスを使用して、エンジン層の各サーバ上の論理アドレスをコンフィグレーションします。(同じ論理 IP アドレスをエンジン層の各サーバ マシン上で重複して使用します)。Oracle WebLogic Communication Services は、コンフィグレーションされているロード バランサの IP アドレス (ネットワーク チャネルのパブリック アドレスとして定義されているアドレス) に一致するローカル サーバ インタフェースを使用して SIP UDP メッセージを発信します。その場合、レイヤ 3 に格納されるアドレスはパブリック アドレスです。
|
警告 : Oracle WebLogic Communication Services の IP マスカレード機能を使用すると、複数のサーバ上で重複した IP アドレスを設定することが必要になるので、ネットワークが不安定な状態になるおそれがあります。プロダクション デプロイメントでは、信頼性の高いネットワーク パフォーマンスを実現するために、IP マスカレードの使用は避け、その代わりに、送信元 NAT を行うようにコンフィグレーションされたロード バランサを使用してください。 |
Oracle Communications Converged Application Server の IP マスカレード機能を無効にするには、次の起動オプションを使用します。
-Dwlss.udp.lb.masquerade=false
Oracle WebLogic Communication Services では SIP 非対応のロード バランサも使用可能です。SIP 非対応のロード バランサとは、サーバへのリクエストをルーティングする際に、進行中の SIP ダイアログを考慮しないロード バランサのことです。このドキュメントでは、ロード バランサと Oracle WebLogic Communication Services のコンフィグレーション、および、さまざまなコンフィグレーションにおいて SIP とネットワーク アドレス変換 (NAT) が相互に及ぼす影響について、実際的な例を示しながら説明します。
以下の節では、Oracle WebLogic Communication Services で SIP 非対応のロード バランサを使用する場合のネットワーク コンフィグレーションについて、ネットワーク コンフィグレーションの具体例を示しながら説明します。
NAT に関する実装固有の問題の詳細については、IETF のドキュメント NAT Behavioral Requirements for Unicast UDP (http://tools.ietf.org/wg/behave/draft-ietf-behave-nat-udp/) を参照してください。
図 4-5 は、この節で説明するネットワーク トポロジの例を示したものです。 この例では、WLSS 1 および WLSS 2 の 2 つのエンジンで構成された Oracle WebLogic Communication Services クラスタが、プライベート IP ネットワーク 10.1/16 (内部的な 16 ビットのサブネット) 上にコンフィグレーションされています。クラスタのパブリック IP アドレスは 1.2.3.4 であり、このアドレスは、ロード バランサ上にコンフィグレーションされている仮想 IP アドレスです。
2.3.4.5 という IP アドレスを持つユーザ エージェント UAC A からは、Oracle WebLogic Communication Services クラスタのアドレスとしてコンフィグレーションされている内部 IP アドレスはまったく認識できません。ユーザ エージェント UAC A は、この内部アドレスではなく、パブリック アドレスの 1.2.3.4 に対してリクエストを送信し、1.2.3.4 から発信された応答を受信します。
以下の節では、この例のシステムの Oracle WebLogic Communication Services クラスタおよびロード バランサのコンフィグレーションについて説明します。
WebLogic SIP Server クラスタのコンフィグレーションでは、各エンジンのパブリック アドレスは 5060、パブリック ポートは 1079038 に設定されています (節 4.2「ロード バランサのアドレスのコンフィグレーション」を参照)。 両方の Oracle WebLogic Communication Services エンジン上のデフォルト ルートは、ロード バランサの 10.1/16 ネットワーク インタフェース : 10.1.3.4 を示します。例 4-4 には、Oracle WebLogic Communication Services （WLSS 1 サーバと WLSS 2 サーバ) のルーティング テーブルを示します。
ロード バランサには 1.2.3.4 という仮想 IP アドレスがコンフィグレーションされており、実際に使用される 2 つのサーバ WLSS 1 および WLSS 2 にはそれぞれ 10.1.1.1 および 10.1.1.2 のアドレスが割り当てられています。また、ロード バランサには、10.1/16 ネットワーク上の内部 IP アドレスである 10.1.3.4 も割り当てられています。UAC のアドレスである 2.3.4.5 は、ロード バランサ上の静的ルートのコンフィグレーションによって、ロード バランサからアクセス可能になっています。例 4-5 に、ロード バランサのルーティング テーブルの内容を示します。
例 4-5 ロード バランサのルーティング テーブル
$ /sbin/route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.0.0 * 255.255.0.0 U 0 0 0 eth1 1.2.0.0 * 255.255.0.0 U 0 0
SIP のユーザ エージェントがリクエストまたは応答を送信する際に使用する送信先 IP アドレスと UDP ポート番号は SIP プロトコル仕様 (RFC 3261) で規定されているため、ロード バランサの NAT コンフィグレーションは RFC 3261 の要件に違反しない形で行う必要があります。そのようなコンフィグレーションは、次の 3 つの設定方法で実現できます。
以下の節で、それぞれのアプローチについて説明します。
ロード バランサの UDP NAT のデフォルトの動作は、パブリック ネットワーク > プライベート ネットワークの方向に転送されるパケット対しては送信先 IP アドレス変換を実行し、プライベート ネットワーク > パブリック ネットワークの方向に転送されるパケットに対しては送信元 IP アドレス変換を実行することです。つまり、UAC > Oracle WebLogic Communication Services (2.3.4.5 -> 1.2.3.4) 方向のパケットに対しては送信元アドレス変換を行わずに送信先アドレス変換だけを実行し、Oracle WebLogic Communication Services > UAC (10.1/16 > 2.3.4.5) 方向のパケットに対しては送信先アドレス変換を行わずに送信元アドレス変換だけを実行するように設定します。
図 4-6 は、SUBSCRIBE/200OK トランザクション の UDP パケットの流れを示したものです。
各 UDP パケットの送信元と送信先の IP アドレスは青字で記してあります。UAC > Oracle WebLogic Communication Services 方向のパケットの転送時にはロード バランサによって送信先 IP アドレス変換が行われますが、送信元 IP アドレスは変換されません。Oracle WebLogic Communication Services > UAC 方向のパケットの転送時にはロード バランサによって送信元 IP アドレス変換が行われますが、送信先 IP アドレスは変換されません。
図 4-6 のシーケンスの (IP ヘッダ、UDP のヘッダ、および SIP ペイロードを含む) 詳細なメッセージ トレースを次の例 4-6 に示します。
例 4-6 SUBSCRIBE の詳細なメッセージ トレース
No. Time Source Destination Protocol Info 1 1.425250 2.3.4.5 1.2.3.4 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 2 2.426250 2.3.4.5 10.1.1.1 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 10.1.1.1 (10.1.1.1) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 3 3.430903 10.1.1.1 2.3.4.5 SIP Status: 200 OK Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5) User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71> CSeq: 1 SUBSCRIBE Call-ID: 1-25923@2.3.4.5
このトランザクションに続いて Oracle WebLogic Communication Services が UAC に向けて NOTIFY リクエストを送信したとすると、次の図 4-7 に示したシーケンスが発生します。
前のシーケンスの場合と同様、Oracle WebLogic Communication Services > UAC 方向のパケットの転送時には送信元 IP アドレス変換が行われ、UAC > Oracle WebLogic Communication Services 方向のパケットの転送時には送信先 IP アドレス変換が行われます。
このセットアップでは、ロード バランサがセッション ステート情報を保持する必要はなく、SIP 対応である必要もありません。図 4-7 のシーケンスの詳細なメッセージ トレースを次の例 4-7 に示します。
例 4-7 NOTIFY の詳細なメッセージ トレース
No. Time Source Destination Protocol Info 1 5.430952 10.1.1.1 2.3.4.5 SIP Request: NOTIFY sip:sipp@2.3.4.5:9999 Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5) User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999) Session Initiation Protocol Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0 Message Header To: sipp <sip:sipp@2.3.4.5>;tag=1 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71> CSeq: 1 NOTIFY Call-ID: 1-25923@2.3.4.5 Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Max-Forwards: 70 No. Time Source Destination Protocol Info 2 6.430952 1.2.3.4 2.3.4.5 SIP Request: NOTIFY sip:sipp@2.3.4.5:9999 Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5) User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999) Session Initiation Protocol Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0 Message Header To: sipp <sip:sipp@2.3.4.5>;tag=1 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71> CSeq: 1 NOTIFY Call-ID: 1-25923@2.3.4.5 Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Max-Forwards: 70 No. Time Source Destination Protocol Info 3 7.431367 2.3.4.5 1.2.3.4 SIP Status: 200 OK Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1 Call-ID: 1-25923@2.3.4.5 CSeq: 1 NOTIFY Contact: <sip:2.3.4.5:9999;transport=UDP>
|
警告 : ロード バランサは通常、リクエストに対する応答では特定の送信先ポート番号が使用されることを前提としてアドレス変換を行うので、送信元 IP アドレス変換 (SNAT) と送信先 IP アドレス変換 (DNAT) の両方の NAT を実行すると、このコンフィグレーションは正常に機能しません。ポート番号の値は RFC 3261 によって規定されていて、Via ヘッダに記述されている値を使用することが必須となっていますが、このことはロード バランサの NAT の要件と衝突します。RFC 3261 の規定により、SIP リクエストに対する応答は、そのリクエストの送信に使用された IP アドレスに対して送信しなければなりません (ただし、節 4.9.3.2「maddr ベースのコンフィグレーション」で説明しているように、Via ヘッダ内に maddr パラメータの値が記述されている場合は、そのパラメータで指定されているアドレスが使用されます)。 したがって、次の図 4-8 の手順 3 では Oracle WebLogic Communication Services からロード バランサの内部 IP アドレス (10.1.3.4) のポート 5060 に対して 200 OK 応答が送信されます。 この応答はその時点で破棄されます。 |
図 4-8 のシーケンスの詳細なメッセージ トレースを次の例 4-8 に示します。
例 4-8 失敗した SUBSCRIBE の詳細なメッセージ トレース
No. Time Source Destination Protocol Info 1 1.425250 2.3.4.5 1.2.3.4 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 2 2.426250 10.1.3.4 10.1.1.1 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1) User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 3 3.430903 10.1.1.1 10.1.3.4 SIP Status: 200 OK Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4) User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999) Session Initiation Protocol
Via ヘッダ内に maddr パラメータの値が記述されている場合、応答はリクエストの送信元の IP アドレスに対してではなく、maddr パラメータで指定されている IP アドレスに送信されます (このことは SNAT が有効に設定されている場合でも同じです)。次の例では、UAC からのリクエストの Via ヘッダ内に maddr パラメータが記述されていて、その値として 2.3.4.5 が設定されています。そのため、SIP サーバからの応答は問題なく UAC に着信します。
図 4-9 のシーケンスの詳細なメッセージ トレースを次の例 4-9 に示します。
例 4-9 maddr が指定されている場合の詳細なメッセージ トレース
No. Time Source Destination Protocol Info 1 1.425250 2.3.4.5 1.2.3.4 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 2 2.426250 10.1.3.4 10.1.1.1 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1) User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;maddr=2.3.4.5;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 3 3.430903 10.1.1.1 2.3.4.5 SIP Status: 200 OK Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5) User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71>
RFC 3581 では、SIP と NAT が相互に及ぼす影響を改善するために、クライアントがサーバに対して、応答の送信先として Via ヘッダに記述されている UDP ポート番号ではなく、リクエストの送信に使用されたポート番号を使用することを要求できるようになっています。この方法で SUBSCRIBE と NOTIFY の両方のメッセージを正常に送受信できるようにするには、UAC と Oracle WebLogic Communication Services の両方で RFC 3581 がサポートされている必要があります。図 4-10 は SUBSCRIBE の流れを示したものです。
図 4-10 のシーケンスの詳細なメッセージ トレースを次の例 4-10 に示します。
例 4-10 rport を使用した場合の SUBSCRIBE の詳細なメッセージ トレース
No. Time Source Destination Protocol Info 1 1.425250 2.3.4.5 1.2.3.4 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 2 2.426250 10.1.3.4 10.1.1.1 SIP Request: SUBSCRIBE sip:subscribe@1.2.3.4:5060 Internet Protocol, Src: 10.1.3.4 (10.1.3.4), Dst: 10.1.1.1 (10.1.1.1) User Datagram Protocol, Src Port: 2222 (2222), Dst Port: sip (5060) Session Initiation Protocol Request-Line: SUBSCRIBE sip:subscribe@1.2.3.4:5060 SIP/2.0 Message Header Via: SIP/2.0/UDP 2.3.4.5:9999;rport;branch=1 From: sipp <sip:sipp@2.3.4.5>;tag=1 To: sut <sip:subscribe@1.2.3.4:5060> Call-ID: 1-25923@2.3.4.5 Cseq: 1 SUBSCRIBE Contact: sip:sipp@2.3.4.5:9999 Max-Forwards: 70 Event: ua-profile Expires: 10 Content-Length: 0 No. Time Source Destination Protocol Info 3 3.430903 10.1.1.1 10.1.3.4 SIP Status: 200 OK Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 10.1.3.4 (10.1.3.4) User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 2222 (2222) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header To: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71> CSeq: 1 SUBSCRIBE Call-ID: 1-25923@2.3.4.5
図 4-11 は NOTIFY の流れを示したものです。
送信元アドレスの NAT は両方向 (UAS > Oracle WebLogic Communication Services および Oracle WebLogic Communication Services > UA) とも有効に設定されていますが、ロード バランサは、リクエストの送信に使用したポートと同じポートに応答が返されるという前提に基づいて、手順 3 の送信先アドレスを適切に識別することができます。 このことは、ロード バランサによってステート情報が保持されていることを意味します。
図 4-11 のシーケンスの詳細なメッセージ トレースを次の例 4-11 に示します。
例 4-11 rport を使用した場合の NOTIFY の詳細なメッセージ トレース
No. Time Source Destination Protocol Info 1 5.430952 10.1.1.1 2.3.4.5 SIP Request: NOTIFY sip:sipp@2.3.4.5:9999 Internet Protocol, Src: 10.1.1.1 (10.1.1.1), Dst: 2.3.4.5 (2.3.4.5) User Datagram Protocol, Src Port: 42316 (42316), Dst Port: 9999 (9999) Session Initiation Protocol Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0 Message Header To: sipp <sip:sipp@2.3.4.5>;tag=1 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71> CSeq: 1 NOTIFY Call-ID: 1-25923@2.3.4.5 Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Max-Forwards: 70 No. Time Source Destination Protocol Info 2 6.430952 1.2.3.4 2.3.4.5 SIP Request: NOTIFY sip:sipp@2.3.4.5:9999 Internet Protocol, Src: 1.2.3.4 (1.2.3.4), Dst: 2.3.4.5 (2.3.4.5) User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 9999 (9999) Session Initiation Protocol Request-Line: NOTIFY sip:sipp@2.3.4.5:9999 SIP/2.0 Message Header To: sipp <sip:sipp@2.3.4.5>;tag=1 Content-Length: 0 Contact: <sip:app-12eomtm5h5f77@1.2.3.4:5060;transport=udp;wlsscid=1ae4479ac6ff71> CSeq: 1 NOTIFY Call-ID: 1-25923@2.3.4.5 Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 Max-Forwards: 70 No. Time Source Destination Protocol Info 3 7.431367 2.3.4.5 1.2.3.4 SIP Status: 200 OK Internet Protocol, Src: 2.3.4.5 (2.3.4.5), Dst: 1.2.3.4 (1.2.3.4) User Datagram Protocol, Src Port: 9999 (9999), Dst Port: (2222) Session Initiation Protocol Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 1.2.3.4:5060;wlsscid=1ae4479ac6ff71;branch=z9hG4bKc5e4c3b4c22be517133ab749adeece4e;rport From: sut <sip:subscribe@1.2.3.4:5060>;tag=82722c03 To: sipp <sip:sipp@2.3.4.5>;tag=1;tag=1 Call-ID: 1-25923@2.3.4.5 CSeq: 1 NOTIFY Contact: <sip:2.3.4.5:9999;transport=UDP
