| Oracle® WebLogic Server SIP Container管理者ガイド 11g リリース1(11.1.1) B61429-02 |
|
 前 |
 次 |
次の項では、Oracle WebLogic Server SIP Containerとともに使用するためにネットワーク・リソースを構成する方法を説明します。
それぞれのOracle WebLogic Server SIP ContainerインスタンスのデフォルトHTTPネットワーク構成は、各サーバーのリスニング・アドレスおよびリスニング・ポートの設定から決定されます。ただし、Oracle WebLogic Server SIP Containerは、HTTP経由でSIPプロトコルをサポートしていません。SIPプロトコルは、UDPおよびTCPトランスポート・プロトコル経由でサポートされます。また、SIPSは、TLSトランスポート・プロトコルを使用してサポートされます。
UDP、TCP、またはTLSトランスポートを有効化するには、Oracle WebLogic Server SIP Containerインスタンスの1つ以上のネットワーク・チャネルを構成します。ネットワーク・チャネルとは構成可能なWebLogic Serverリソースで、サーバー・インスタンスへの固有のネットワーク接続の属性を定義します。基本チャネル属性には次が含まれます。
接続でサポートされているプロトコル
接続で使用されるポート番号
発信されるUDPパケットで使用されるポート番号(オプション)
チャネルを発信接続に使用する場合にSIPヘッダーに埋め込まれるパブリック・リスニング・アドレス(ロード・バランサのアドレス)
複数のチャネルを単一のOracle WebLogic Server SIP Containerインスタンスに割り当てて、複数のプロトコルのサポートまたはDNSサーバー・ハードウェアで使用可能な複数のインタフェースを活用できます。同一のチャネルを複数のサーバー・インスタンスに割り当てできません。
SIPプロトコル用の新しいネットワーク・チャネルを構成すると、UDPおよびTCPトランスポート・プロトコルの両方が指定されたポートで有効です。UDPまたはTCPのどちらか一方のトランスポート・プロトコルのみを使用するSIPチャネルを作成することはできません。SIPSプロトコル用のネットワーク・チャネルを構成すると、そのチャネルの接続では、トランスポート・プロトコルとしてTLSが使用されます。
新しいSIP Serverドメインを構成する場合は、通常、システム内のエンジン層の各サーバーとの通信に使用する複数のSIPチャネルを作成する必要があります。エンジン層のサーバーは、レプリカ用に構成されたリスニング・アドレス属性を使用して、SIPデータ層のレプリカと通信できます。ただし、レプリカ間で相互に通信するには、レプリカで一意なリスニング・アドレスを使用する必要があります。
|
注意: SIPデータ層クラスタで複数のレプリカを構成する場合、各サーバーの一意のリスニング・アドレス(一意のDNS名またはIPアドレス)を構成する必要があります。一意のリスニング・アドレスを指定しない場合、レプリカ・サービスはデフォルトのlocalhostアドレスにバインドし、複数のレプリカは相互に検索できません。 |
オペレーティング・システムおよびハードウェアがIPv6をサポートしている場合、ネットワーク通信にIPv6を使用するためにOracle WebLogic Server SIP Containerも構成できます。SIPトラフィックのIPv6は、IPv6アドレスを使用してネットワーク・チャネルを構成することによって有効化されます。IPv6トラフィックをサポートする各エンジン層サーバー上でIPv6 SIPチャネルを構成する必要があります。手順については、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照してください。
エンジン上で構成した各SIPネットワーク・チャネルは、IPv6またはIPv4トラフィックをサポートします。1つのチャネルでIPv4とIPv6トラフィックをいっしょに使用することはできません。1つのエンジンは、複数の個別のネットワークをサポートするために、IPv4とIPv6チャネルの両方で構成できます。
外部SIPトラフィックの他のプロトコル・バージョンをサポートする一方で、Oracle WebLogic Server SIP ContainerエンジンおよびSIPデータ層ノードがIPv4(またはIPv6)上で通信できます。IPv6ネットワークでエンジンおよびSIPデータ層ノードを構成するには、各サーバー・インスタンスに対してIPv6リスニング・アドレスを指定します。
IPv4とIPv6ネットワーク・チャネルの構成に関する詳細は、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照してください。
システムが、エンジン層への接続を分散するために1つ以上のロード・バランサを使用する場合、外部リスニング・アドレスとしてロード・バランサ・アドレスを含めるようにSIPネットワーク・チャネルを構成する必要があります。SIPチャネルが、チャネルのプライマリ・リスニング・アドレスとは異なる外部リスニング・アドレスを持つとき、Oracle WebLogic Server SIP Containerは、ResponseなどのSIPヘッダーに外部アドレスのホストおよびポート番号を埋め込みます。このように、呼出しに対する後続の通信は、ローカル・エンジン層サーバー・アドレス(外部クライアントにアクセスできない)ではなく、パブリック・ロード・バランサ・アドレスに直接接続されます。
ネットワーク・チャネルにおいて外部リスニング・アドレスが構成されていない場合は、そのチャネルのプライマリ・リスニング・アドレスがSIPヘッダーに埋め込まれます。
システムが2つのロード・バランサを使用する場合、各エンジン層サーバー(各ロード・バランサへの各ネットワーク接続)上で2つのチャネルを定義し、外部リスニング・アドレスを対応するロード・バランサに割り当てる必要があります。エンジン層サーバー上で特定のネットワーク・インタフェースがアウトバウンド・トラフィックに選択されるとき、そのネットワーク・インタフェース・カード(NIC)アドレスに関連するネットワーク・チャネルは、SIPヘッダーに埋め込むための外部リスニング・アドレスを決定するために確認されます。
2つのパブリック・アドレスを持つDNSロード・バランサを使用する場合、2つのチャネルを定義して、その両方のパブリック・アドレスを構成する必要もあります。エンジン層サーバーに搭載されているNICが1つのみのときは、2番目のパブリック・アドレス専用のチャネルを構成するために、そのNICの2番目のアドレスを論理アドレスとして定義します。さらに、IPルーティング・ポリシーを構成して、ロード・バランサのそれぞれのパブリック・アドレスにどの論理アドレスを関連付けるかを指定することも必要です。
Oracle WebLogic Server SIP Containerは、SIPメッセージを送信するために必要なプロキシのポート番号、トランスポートおよびIPアドレスを解決するDNSをサポートします。これは、RFC 3263(http://www.ietf.org/rfc/rfc3263.txt)で説明されている動作に一致します。また、DNSは、宛先のIPアドレスおよびポート番号を解決するために、レスポンスをルーティングするときに使用される場合もあります。
|
注意: DNS解決はSIPメッセージ処理のコンテキスト内で実行されるため、どのようなDNSパフォーマンス問題でも待機時間増加の原因となります。潜在的なパフォーマンス問題を削減するために本番環境ではキャッシングDNSサーバーを使用することをお薦めします。 |
DNSサポートのコンフィグレーション手順
構成対象のOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。
コンソールの左ペインで「SipServer」ノードを選択します。
右ペインで「構成」>「全般」タブを選択します。
「DNSサーバー・ルックアップの有効化」を選択してください。
「保存」をクリックして変更を保存します。
DNSルック・アップを有効にすると、サーバーは以下の目的でDNSを使用できます。
リクエストがSIP URIに送信されるとき、プロキシ・サーバーのトランスポート、IPアドレス、およびポート番号を検出します。
Sent-byフィールドのコンテンツに応じて、レスポンスのルーティング中にIPアドレスまたはポート番号(あるいはその両方)を解決します。
プロキシの検出では、Oracle WebLogic Server SIP Containerは、トランスポート、IP、およびポート番号情報を判定するためにSIPトランザクションごとに1回のみDNS解決を使用します。すべての再送信、ACK、またはCANCELリクエストは、同一のトランスポートを使用して同一のアドレスおよびポートに送信されます。DNS解決発現の方法に関する詳細は、RFC 3263 (http://www.ietf.org/rfc/rfc3263.txt)を参照してください。
レスポンス・メッセージの送信にプロキシが必要なとき、Oracle WebLogic Server SIP Containerは、Sent-byフィールドおよびヘッダーによって提供される情報に応じて、宛先のIPアドレスまたはポート番号(あるいはその両方)を決定するためにDNS参照を使用します。
構成ウィザードを使用して新しいドメインを作成するとき、Oracle WebLogic Server SIP Containerインスタンスは、UDPおよびTCP経由でSIPプロトコルをサポートするデフォルトのネットワーク・チャネルを使用して構成されます。このデフォルト・チャネルは、リスニング・ポート5060番を使用するように構成されますが、リスニング・アドレスは指定しません。デフォルト・チャネルのリスニング・アドレスおよびリスニング・ポートの設定を変更するためには、3.4.1項「既存チャネルの再構成」の手順に従ってください。追加プロトコルまたは追加ネットワーク・インタフェースをサポートするための新しいチャネル・リソースを作成するためには、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照してください。
既存チャネルにサポートされているプロトコルは変更できません。異なるネットワーク・プロトコルを使用するための既存リスニング・アドレス/ポートの組合せを再構成するには、既存チャネルを削除し、3.4.2項「新規SIPまたはSIPSチャネルの作成」の手順を使用して新しいチャネルを作成します。
チャネルを構成するには、次の手順を実行します。
構成対象のOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。
左ペインで、「環境」>「サーバー」タブを選択します。
右ペインで、構成するサーバーの名前を選択します。
「プロトコル」>「チャネル」タブを選択し、構成済チャネルを表示します。
既存チャネルを削除するには、表で選択して「削除」をクリックします。
既存チャネルを再構成するには、次の手順を実行します。
チャネル・リストからチャネルの名前を選択します(デフォルトの「SIP」チャネルなど)。
関連するエンジン層マシン上でNICのアドレスまたは論理アドレスに対応するように、「リスニング・アドレス」または「リスニング・ポート」フィールドを編集します。
|
注意: リスニング・アドレスとリスニング・ポートを変更する前に、チャネルを無効にする必要があります。 |
「外部リスニング・アドレス」フィールドまたは「外部リスニング・ポート」フィールドを編集して、システムのロード・バランサのパブリック・アドレスに一致するように変更します。
必要に応じて上級チャネル属性を編集します(詳細は、3.4.2項「新規SIPまたはSIPSチャネルの作成」を参照)。
「保存」をクリックします。
Oracle WebLogic Server SIP Containerインスタンスの構成への新規SIPまたはSIPSチャネルを作成するには、次の手順を実行します。
構成対象のOracle WebLogic Server SIP Containerドメインの管理コンソールにログインします。
左ペインで、「環境」>「サーバー」タブを選択します。
右ペインで、構成するサーバーの名前を選択します。
「プロトコル」>「チャネル」タブを選択し、構成済チャネルを表示します。
「新規」をクリックし、新規チャネルを構成します。
新規チャネルの各フィールドの値を以下のように指定します。
名前: SIPS-Channel-eth0などの、このチャネルの管理名を入力します。
プロトコル: UDPおよびTCPトランスポートをサポートするために「SIP」を選択するか、またはTLSトランスポートをサポートするためにSIPSを選択します。SIPチャネルは、構成済ポート上でUDPトランスポートのみまたはTCPトランスポートのみはサポートできないので注意してください。
「次へ」をクリックします。
次のように、新規チャネルのアドレス・フィールドを記入します。
「リスニング・アドレス」: このチャネルのIPアドレスまたはDNS名を入力します。DNSマシンの場合は、構成対象のインタフェースの正確なIPアドレス、または正確なIPアドレスにマッピングされるDNS名を入力します。
「リスニング・ポート」: このチャネルを通して通信に使用されるポート番号を入力します。リスニング・アドレスおよびリスニング・ポートの組合せは、サーバーに構成されたすべてのチャネル全体に渡って一意である必要があります。SIPチャネルは、構成済ポート上でUDPおよびTCPトランスポートの両方をサポートしています。
「外部リスニング・アドレス」および「外部リスニング・ポート」:これらのフィールドを編集し、このチャネルに関連するロード・バランサのパブリック・アドレスと照合します。サーバーが、アウトバウンド・ネットワーク・トラフィックに使用するためにインタフェースまたは論理アドレスを選択するとき、Oracle WebLogic Server SIP Containerは、同一のプライマリ・リスニング・アドレスを使用して構成されたチャネルを確認します。このチャネルの「外部リスニング・アドレス」が異なる場合、外部アドレスは以降のコール・トラフィック用にSIPメッセージ・ヘッダーに埋め込まれます。詳細は、3.2項「ロード・バランサ・アドレスの構成」を参照してください。
「次へ」をクリックします。
オプションで、「表示」をクリックし、「接続タイムアウト」値などの上級チャネル・プロパティを表示して編集します。上級チャネル・プロパティの次の制約および提案があることに注意してください。
「アウトバウンドの有効化」: この属性は、すべてのSIPおよびSIPSチャネルがネットワーク接続の起点となるため、チェックされません。
「このプロトコルでHTTPを有効化」: この属性は、Oracle WebLogic Server SIP ContainerがHTTPトランスポートSIPプロトコルをサポートしないため、SIPおよびSIPSチャネルに選択できません。
「最大メッセージ・サイズ」: この属性は、サーバーがこのチャネルからの接続で許可する最大TCPメッセージ・サイズを指定します。Oracle WebLogic Server SIP Containerは、メッセージ・サイズが構成済の値を超過する接続を切断します。デフォルト・サイズの10,000,000バイトは大容量です。サーバーに対するサービス拒否(DOS)攻撃を防ぐことを懸念するなら、デプロイされたサービスに体操する値までこの属性を削減します。
「終了」をクリックします。
SIPチャネルは、1つ以上のカスタム・チャネル・プロパティを使用して構成できます。カスタム・プロパティは、管理コンソールを使用して設定できません。そのかわり、テキスト・エディタを使用して、ドメインのconfig.xmlファイルのチャネル構成部分で単一のcustom-propertyスタンザにプロパティを追加する必要があります。
Oracle WebLogic Server SIP Containerによって、SIPチャネルのトランスポート・プロトコルに影響を与える次のカスタム・プロパティが提供されます。
TcpConnectTimeoutMillis: Oracle WebLogic Server SIP Containerが、(アウトバウンドTCP接続の)宛先アドレスを受信不能と宣言するまでの待機時間を指定します。このプロパティはSIPチャネルにのみ適用できます。Oracle WebLogic Server SIP ContainerはSIPSチャネルのこの属性値を無視します。値を0に指定すると、タイムアウトを完全に無効化できます。デフォルト値の3000ミリ秒は、カスタム・プロパティを指定しない場合に使用されます。
SctpConnectTimeoutMillis: Oracle WebLogic Server SIP Containerが、(アウトバウンドSCTP接続の)宛先アドレスを受信不能と宣言するまでの待機時間を指定します。このプロパティは、(Diameterトラフィックの)SCTPチャネルにのみ適用できます。値を0に指定すると、タイムアウトを完全に無効化できます。デフォルト値の3000ミリ秒は、カスタム・プロパティを指定しない場合に使用されます。DiameterのSCTPチャネルの作成に関する詳細は、3.8.1.1項「アウトバウンドUDPパケットの静的なポート構成」を参照してください。
SourcePorts: UDPパケットの発信にサーバーが使用する1つ以上の静的なポート番号を構成します。
|
注意: 大半の構成において、SourcePortsカスタム・プロパティの使用は、パフォーマンスを低下させるためお薦めしません。このプロパティは、Oracle WebLogic Server SIP ContainerがUDPパケットの発信に使用する正確なポートを指定する必要がある場合にのみ構成します。 |
Mtu: このチャネルの最大送信単位(MTU)を指定します。値を-1に指定すると、トランスポートのデフォルトのMTUを使用します。
EnabledProtocolVersions: Oracle WebLogic Server SIP ContainerがSSLクライアントとして機能するときに、このチャネルで使用するSSLプロトコルのバージョンを指定します。SSLクライアントとして機能するとき、デフォルトでチャネルにはサポートされるプロトコルとしてTLS V1.0が必要です。サーバーは、SSL V3.0がSSLピア・サーバーによってサポートされる最上位バージョンである場合、SSL V3.0も使用するように構成できます。このプロパティの次の値のいずれかを設定できます:
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を直接編集するとき、custom-properties要素を1つのみチャネルの構成スタンザの最後に追加するようにしてください。例3-1に示されるように、セミコロン(;)を使用して同一要素内の複数のカスタム・プロパティを区切ります。
例3-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>
複数のネットワーク・インタフェースを持つサーバー(DNSサーバー)を構成する場合、Oracle WebLogic Server SIP Containerによって使用される各IPアドレスの個別のネットワーク・チャネルを構成する必要があります。Oracle WebLogic Server SIP Containerは、ルーティング情報をSIPメッセージ・システム・ヘッダーに埋め込むときに、各チャネルのリスニング・アドレスおよびリスニング・ポートの値を使用します。
|
注意: DNSマシン上で特定のIPアドレスのチャネルを構成しない場合、そのIPアドレスはVia、Contact、およびRecord-Routeヘッダーを移入するときに使用できません。 |
Oracle WebLogic Server SIP Container Diameter実装は、TCPまたはTLSトランスポート・プロトコル経由でDiameterプロトコルをサポートします。サーバー上で受信Diameter接続を有効化するには、TCPトランスポートのプロトコル・タイプdiameterまたはTCPおよびTLSトランスポート両方のdiametersを使用して専用ネットワーク・チャネルを構成します。Diameter実装アプリケーションは、Diameter 仕様書(RFC 3558)に記載されているように、自動的にDiameter接続をアップグレードしてTLSを使用する場合があります。
Diameterプロトコル・サポートのネットワーク・チャネルの構成に関する詳細は、第6章「Diameterクライアント・ノードおよびリレー・エージェントの構成」を参照してください。
任意の使用可能なIPインタフェース上でUDPトラフィックをリスニングするようにOracle WebLogic Server SIP Containerを構成するには、新規SIPチャネルを作成し、リスニング・アドレスとして0.0.0.0(または、IPv6ネットワークの場合は::)を指定します。SIPメッセージの送信に使用する明示的なIPアドレスを使用して少なくとも1つの追加チャネルは構成する必要があります。(DNSマシンでは、メッセージ送信用の各インタフェースは必ず構成済チャネルを持つ必要があります。)
|
注意: 0.0.0.0構成を使用すると、Linuxプラットホーム上のUDPトラフィックにのみ影響があります。Oracle WebLogic Server SIP Containerは、サーバーの構成済ホスト名およびlocalhostに対応するTCP/HTTPリスニング・スレッドのみ作成します。複数のアドレスがホスト名にマップされている場合、Oracle WebLogic Server SIP Containerは起動時に警告メッセージを表示します。この問題を避け、すべてのアドレス上でリスニングするには、::アドレスを指定します。このアドレスは、HTTP/TCPトラフィックのIPv6およびIPv4の両方に使用可能なすべてのアドレスも含みます。 |
SIPデータ層のレプリカがピアとして相互に通信できるようにするには、一意なリスニング・アドレス属性(一意なDNS名またはIPアドレス)を各レプリカにバインドする必要があります。各レプリカに一意なリスン・アドレスを割り当てるには、次の手順を実行します。
Oracle WebLogic Server SIP Containerドメインの管理コンソールにアクセスします。
左ペインから「環境」>「サーバー」を選択します。
右ペインで、構成するサーバーの名前を選択します。
「構成」>「全般」タブを選択します。
「リスニング・アドレス」フィールドで一意のDNS名またはIPアドレスを入力します。
「保存」をクリックします。
Oracle WebLogic Server SIP Containerの本番インストールの大半(エンタープライズ・デプロイメント)には、1つ以上の次の特性が含まれます。
複数のエンジン層サーバーによってクラスタが構成されています。
エンジン層の各サーバー・インスタンスが複数のネットワーク・チャネルを持ち、複数のSIPトランスポート・プロトコル、またはDNSハードウェア上の複数のネットワーク・インタフェース・カード(NIC)がサポートされています。
1つ以上のロード・バランサ、またはDNSロード・バランサがあり、サーバーのフェイルオーバーや、必要に応じて、ソースまたはネットワーク・パケットのネットワーク・アドレス変換(NAT)を実行できます。
このような各種のネットワーク要素が組み合わされて使用されていると、各要素が互いにどのように作用し合い、ネットワーク要素や構成オプションの特定の組合わせがSIPメッセージまたはトランスポート・プロトコル・データ・グラムの内容にどのような影響を与えるのかが理解しにくくなる場合があります。
次の項では、共通Oracle WebLogic Server SIP Containerネットワーク・アーキテクチャを解説し、各アーキテクチャでサーバーが構成される仕組みを説明しています。また、SIPメッセージおよびトランスポート・データグラム内の情報が、各構成によってどのように影響を受けるかについても説明しています。図3-1は、異なるネットワーク構成によって影響を受ける可能性がある通常のOpen Systems Interconnect (OSI)モデル・レイヤーを示しています。
図3-1 Oracle WebLogic Server SIP Containerのネットワーク構成によって影響を受けるOSIレイヤー
レイヤー3 (ネットワーク層)およびレイヤー4 (トランスポート層)には、発信および受信されるトランスポート・データ・グラムの送信元または送信先IPアドレスとポート番号が格納されています。SIPプロトコルでは、SIPメッセージの送信元にアクセスするためのアドレス情報を特定のSIPヘッダー内に記述するように規定されているので、レイヤー7 (アプリケーション層)も影響を受ける可能性があります。
NICが1枚搭載されたサーバーを使用する単純なネットワーク構成では、1つ以上のネットワーク・チャネルを作成して、UDPおよびTCP経由のSIPメッセージ、またはTLS経由のSIPSメッセージをサポートできます。この単純な構成がOSIモデルの情報にどのように影響するかを把握しておくと、DNSハードウェアおよびロード・バランサを使用したさらに複雑な構成が、同じ情報にどのような影響を与えるかが理解できます。
図3-2は、単一のNICを持つ単一のエンジン層サーバー・インスタンスを示します。このサーバーは、UDPおよびTCP経由でSIPをサポートする1つのネットワーク・チャネルを使用して構成されます。(SIPチャネルは、常にUDPおよびTCPトランスポートをサポートしますが、2つの内1つしかサポートできません)図3-2は、1つはUDP経由、もう1つはTCP経由でサーバーと通信する2つのクライアントも示しています。
TCPトランスポートでは、送信データグラム(Oracle WebLogic Server SIP ContainerからUAへ送信)に次の情報が含まれます。
レイヤー3には、そのネットワーク・チャネルで指定されている送信元IPアドレス(上記例では10.1.1.10)が含まれています。
レイヤー4には、基盤のオペレーティング・システムによって割り当てられた送信元ポート番号が含まれています。
受信TCPデータグラム(UAからOracle WebLogic Server SIP Containerへ送信)には、次の情報が含まれます。
レイヤー3には、そのネットワーク・チャネルで指定されている送信先IPアドレス(10.1.1.10)が含まれています。
レイヤー4には、そのネットワーク・チャネルで指定されている送信先ポート番号(5060)が含まれています。
送信UDPデータグラムでは、OSIレイヤー情報にTCPトランスポートと同一の情報が含まれます。受信UDPデータグラムでは、受信データグラム・レイヤー4情報の場合を除き、OSIレイヤー情報はTCPと同一になります。受信UDPデータグラムでは、レイヤー4には次のいずれかが含まれます。
そのネットワーク・チャネルで指定されている送信先ポート番号(5060)
以前にOracle WebLogic Server SIP Containerによって割り当てられたエフェメラル・ポート番号。
デフォルトでは、Oracle WebLogic Server SIP Containerは、基礎となるオペレーティング・システムのエフェメラル・ポート番号の範囲からポートを送信UDPデータグラムに割り当てます。Oracle WebLogic Server SIP Containerによって、ネットワーク・チャネルに構成されたポート番号に加えて、外部接続が宛先ポート番号としてエフェメラル・ポイントを使用できるようになります。つまり、Oracle WebLogic Server SIP Containerは、サーバーが割り当てるすべてのエフェメラル・ポート上で自動的にリスニングします。オプションで、サーバー起動時に次のオプションを指定することによって、Oracle WebLogic Server SIP Containerによるエフェメラル・ポート番号の使用を無効化できます。
-Dwlss.udp.listen.on.ephemeral=false
サーバー・ログ・ファイルを確認することによって、Oracle WebLogic Server SIP Containerによる特定のエフェメラル・ポートの使用を決定できます。
<Nov 30, 2005 12:00:00 AM PDT> <Notice> <WebLogicServer> <BEA-000202> <Thread "SIP Message Processor (Transport UDP)" listening on port 35993.>
Oracle WebLogic Server SIP Containerネットワーク・チャネルによって、サーバーが発信UDPパケットに使用する1つ以上の静的なポートの構成に使用できるSourcePorts属性が提供されます。
|
注意: 大半の構成において、SourcePortsカスタム・プロパティの使用は、パフォーマンスを低下させるためお薦めしません。このプロパティは、Oracle WebLogic Server SIP ContainerがUDPパケットの発信に使用する正確なポートを指定する必要がある場合にのみ構成します。 |
SourcePortsプロパティを構成するには、WLSTなどのJMXクライアントを使用するか、またはカスタム・プロパティを含むようにconfig.xmlでネットワーク・チャネル構成を直接変更します。SourcePortsは、ポート番号の配列またはポート番号範囲を定義します。SourcePorts定義にスペースが含まれません。ポート番号のみを使用し、ポート範囲を指定するにはハイフン(-)、範囲または各ポートを区切るにはカンマ(,)を使用します。例として使用する構成については、例3-2を参照してください。
例3-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が搭載されDNSサーバー・ハードウェアが利用されます。DNSハードウェアは、一般に、次のいずれかの目的で使用されます。
同一のサブネット内での冗長なネットワーク接続の実現。複数のNICを使用すると、いずれか1つのNICに障害が発生した場合でも、それ以外の1つまたは複数のネットワーク接続を使用して、データ層サーバーまたは管理サーバーと通信することができます。
2つ以上の異なるサブネット全体でSIP通信のサポート。たとえば、Oracle WebLogic Server SIP Containerは、UAがサブネット全体に直接通信できないとき、1つのサブネット内のUAからセカンド・サブネット内のUAへのSIPリクエストを代理するように構成されることがあります。
構成要件およびOSIレイヤー情報は、システムにおけるDNSハードウェアの使用に応じて異なります。複数のNICがサブネット内の冗長接続を提供するために使用されるとき、サーバーは通常、3.8.3項「すべてのアドレス(IP_ANY)にリスニングするDNSサーバー」で説明されているように、すべての使用可能なアドレス(IP_ANY)にリスニングするように構成されます。
異なるサブネットをサポートするために複数のNICを使用するとき、3.8.4項「複数のサブネットにリスニングするDNSサーバー」で説明されているように、各NICのサーバー上で複数のネットワークを構成する必要があります。
最も単純なDNS構成によって、Oracle WebLogic Server SIP Containerインスタンスは、IP_ANYとして記載されることがある、すべての使用可能なNIC(物理NICおよび論理NIC)にリスニングできるようになります。これを達成するには、単一のネットワーク・チャネルを構成し、チャネル・リスニング・アドレスを0.0.0.0に指定します。
0.0.0.0アドレスは、サーバーのネットワーク・チャネル上で直接構成する必要があるので注意してください。チャネルにIPアドレスを指定しない場合、チャネルはサーバー・インスタンス自体に構成されたリスニング・アドレスを継承します。詳細は、3.6項「任意のIPインタフェース上でリスニングするエンジン・サーバーの構成」を参照してください。
また、複数のNICは、複数のサブネット上でリスニングするようにエンジン層サーバーで使用できます。最も一般的な構成では、1つのサブネットからサブネット間の直接アクセスが許可されていない別のサブネットへのSIPトラフィックを代理するために、Oracle WebLogic Server SIP Containerを使用します。図3-3はこの構成を示しています。
図3-3におけるOracle WebLogic Server SIP Containerインスタンスを構成するには、サーバー・マシン上で使用される各NICの個別のネットワーク・チャネルを定義する必要があります。例3-3では、サンプル構成のチャネルを定義するconfig.xmlエントリを示しています。
例3-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 Server SIP Containerが複数のサブネット上でリスニングするように構成されているとき、ルート・リゾルバという機能が次のアクティビティを行います。
OSIレイヤー7情報内に(Via、ContactなどのSIPシステム・ヘッダーに)、正しいアドレスが格納されます。
OSIレイヤー3情報内に、正しい送信元IPアドレスが格納されます。
たとえば、図3-3で示される構成では、Oracle WebLogic Server SIP Containerは、各UAがSIPトランザクションの処理を続けるために、正しいサブネット・アドレスをSIPシステム・ヘッダーおよびトランスポート・データグラムに追加する必要があります。間違ったサブネットが使用される場合、どのUAも別のUAのサブネットに直接アクセスできないため、レプリカは送信されません。
ルート・リゾルバは、データグラムを所定の宛先に送信するためにどのNICをオペレーティング・システムが使用するかを決定してから、そのNICに関連するネットワーク・チャネルを確認することによって機能します。次に、選択されたネットワーク・チャネルで構成されたアドレスを使用し、SIPヘッダーおよびレイヤー3アドレス情報を移入します。
たとえば、図3-3で示される構成では、Oracle WebLogic Server SIP ContainerからUAC Bへ送信されるINVITEメッセージは、10.2.1.16という宛先アドレスを持ちます。オペレーティング・システムは、対応するサブネットに構成されるNIC Bを使用して、このメッセージを送信します。ルート・リゾルバは、NIC Bを構成されたsipchannelBに関連付け、チャネルのIPアドレス(10.2.1.10)をSIPメッセージのVIAヘッダーに埋め込みます。次に、正しいIPアドレスを使用して後続のメッセージをサーバーへ直接送信するために、UAC BはVIAヘッダーを使用します。メッセージが正しいサブネット上でのみ送信されるようにするため、同様のプロセスがUAC Aに使用されます。
IPの別名は複数の論理IPを単一のNICに割り当て、基礎となるサーバーのオペレーティング・システムで構成されます。IP別名を構成し、すべての論理IPアドレスが同一のサブネット内にある場合、3.8.3項「すべてのアドレス(IP_ANY)にリスニングするDNSサーバー」で説明されているように、Oracle WebLogic Server SIP Containerがすべてのアドレスにリスニングするように構成できます。
異なるサブネット上で複数の論理IPアドレスを作成するためにIP別名を構成する場合、各論理IPアドレスに個別のネットワーク・チャネルを構成する必要があります。この構成では、Oracle WebLogic Server SIP Containerはすべての論理アドレスを個別の物理インタフェース(NIC)として処理し、ルート・リゾルバを使用して、構成済チャネルに基づいてOSIレイヤー4およびレイヤー7情報を移入します。
フェイルオーバー機能の提供および複数のサーバーに渡るクライアント・ロードの分散に加え、ロード・バランサは、クライアントとサーバー間で送信されるネットワーク情報を構成するための重要なツールでもあります。次の項では、Oracle WebLogic Server SIP Containerで使用される共通ロード・バランサの構成を説明しています。
最も一般的なロード・バランサの構成は、図3-4で示されるように、エンジン層サーバーのクラスタへのアクセスを開く単一のロード・バランサを活用します。
図3-4で示されるように、単一のロード・バランサとともに使用するためにOracle WebLogic Server SIP Containerを構成するには、各サーバーに1つ以上のネットワーク・チャネルを構成し、ロード・バランサの仮想IPアドレスを使用して各チャネルのパブリック・アドレスを構成します。この構成では、クライアントが後続のレプリカのクラスタに到達できるようにするために、Oracle WebLogic Server SIP Containerはロード・バランサのIPアドレスをSIPメッセージ・ヘッダーに埋め込みます。第3章「ネットワーク・リソースの管理」では、ロード・バランサのアドレスを使用してネットワーク・チャネルを構成するための詳細な手順を提示しています。
|
注意: ロード・バランス・スイッチの一部は、同一エンジン層サーバーへの所定の呼出しですべてのSIPメッセージを自動的に再ルーティングできますが、この機能はOracle WebLogic Server SIP Containerインストールには必要ありません。詳細は、7.7項「代替構成」を参照してください。 |
複数のロード・バランサ(またはDNSロード・バランサ)は、単一のOracle WebLogic Server SIP Containerクラスタの仮想IPアドレスをいくつか提供するために構成できます。DNSロード・バランサとともに使用するためにOracle WebLogic Server SIP Containerを構成するには、各ロード・バランサまたはローカル・サーバーNICの専用ネットワーク・チャネルを作成し、チャネルのパブリック・アドレスを適切なロード・バランサの仮想IPアドレスに設定します。この構成では、ルート・リゾルバは構成済チャネルを発信SIPメッセージに使用されるNICに関連付けます。次に、選択したチャネルのパブリック・アドレスは、SIPシステム・メッセージの移入に使用されます。詳細は、3.8.4.1項「ルート・リゾルバの理解」を参照してください。
最も一般的なケースでは、クライアントが1つ以上の内部(プライベート)Oracle WebLogic Server SIP Containerアドレスとの通信に使用するパブリックIPアドレスを提供するために、ロード・バランサは宛先NATを使用して構成されます。また、ロード・バランサは、ソースNATを使用して構成される場合もあります。このNATは、ロード・バランサ自体の仮想IPアドレスを照合するためにプライベート・アドレスから発信されるレイヤー3アドレス情報を変更します。
デフォルトのルート・リゾルバの動作を使用して、Oracle WebLogic Server SIP Containerエンジンは、ローカルNICのアドレス(プライベート・アドレス)に一致するソースIPアドレスを持つUDPパケットを発信します。これは、ローカル・サーバー・アドレスがパブリックではアクセスできないことがあるため、トランスポート・パケットに埋め込まれたレイヤー3アドレスに直接応答しようとするアプリケーションでは問題になる可能性があります。アプリケーションでこの問題が発生する場合、トランスポート・レイヤー3アドレスをパブリックでアクセス可能な仮想IPアドレスへ変更するためのソースNATを実行するようにロード・バランサを構成することをお薦めします。
ロード・バランサ上でソースNATを有効化しないように選択する場合、Oracle WebLogic Server SIP Containerによって限定IPマスカレード機能が提供されます。この機能を使用するには、クラスタのロード・バランサのパブリックIPアドレスを使用して、各エンジン層サーバーで論理アドレスを構成します。(各エンジン層サーバー・マシン上で同一の論理IPを複製します)ローカル・サーバー・インタフェースが、構成されたロード・バランサ(ネットワーク・チャネルのパブリック・アドレスで定義される)のIPアドレスに一致するとき、Oracle WebLogic Server SIP Containerはこのインタフェースを使用してSIP UDPメッセージを発信し、レイヤー3アドレスにはパブリック・アドレスが含まれます。
|
注意: Oracle WebLogic Server SIP ContainerのIPマスカレード機能を使用すると、複数のサーバー上で複製IPアドレスが必要になるので、ネットワークが不安定になる可能性があります。本番デプロイメントは、信頼性の高いネットワーク・インタフェースを保証するため、IPマスカレード機能ではなく、ソースNATに構成されたロード・バランサを使用する必要があります。 |
Oracle Communications Converged Application ServerのIPマスカレード機能を無効にするには、次の起動オプションを使用します。
-Dwlss.udp.lb.masquerade=false
Oracle WebLogic Server SIP Containerは、SIPを認識できないロード・バランサに対応しているため、リクエストをサーバーにルーティングするとき、既存のSIPダイアログを考慮しません。このドキュメントによって、ロード・バランサおよびOracle WebLogic Server SIP Containerの構成とともに、各種構成におけるSIPとネットワーク・アドレス変換(NAT)との相互作用が実証されます。
次の項では、SIPを認識できないロード・バランサを使用するOracle WebLogic Server SIP Containerのサンプル・ネットワーク構成を説明します。
NATに関する実装依存問題の詳細は、IETFドキュメントのhttp://tools.ietf.org/wg/behave/draft-ietf-behave-nat-udp/にあるユニキャストUDPのNAT動作要件に関する項を参照してください。
図3-5は、この項で説明されているサンプル・ネットワーク・トポロジを示します。Oracle WebLogic Server SIP Containerクラスタは、WLSS 1およびWLSS 2エンジンから成り、プライベートIPネットワーク10.1/16(内部16ビット・サブネット)上で構成されます。クラスタのパブリックIPアドレスは1.2.3.4で、ロード・バランサ上で構成される仮想IPアドレスです。
ユーザー・エージェントUAC Aは2.3.4.5のIPアドレスを持ち、Oracle WebLogic Server SIP Containerクラスタに構成された内部IPアドレスを参照しません。そのかわり、1.2.3.4へリクエストを送信し、そこからレスポンスを受信します。
次の項では、このサンプル・システムのOracle WebLogic Server SIP Containerクラスタおよびロード・バランサの構成を説明しています。
Oracle WebLogic Server SIP Containerクラスタ構成は、各エンジンのパブリック・アドレスを1.2.3.4、パブリック・ポートを5060番(3.2項「ロード・バランサ・アドレスの構成」を参照)に指定します。Oracle WebLogic Server SIP Containerの両エンジン上のデフォルト・ルートは、ロード・バランサの10.1/16ネットワーク・インタフェース(10.1.3.4)を指します。Oracle WebLogic Server SIP Container(WLSS 1およびWLSS 2サーバー)のルーティング表は、例3-4で示されます。
ロード・バランサは、仮想IPアドレス「1.2.3.4」、アドレス「10.1.1.1」および「10.1.1.2」をそれぞれ持つ2つの実際のサーバーWLSS 1およびWLSS 2によって構成されます。また、ロード・バランサは、10.1/16ネットワーク上で構成された内部IPアドレス「10.1.3.4」を持ちます。UACアドレス「2.3.4.5」は、ロード・バランサ上の静的なルーティング構成によってロード・バランサから受信可能です。ロード・バランサのルーティング表は、例3-5で示されています。
例3-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 Server SIP Container (2.3.4.5 > 1.2.3.4)方向の宛先アドレス変換、および宛先アドレス変換なしのOracle WebLogic Server SIP Container > UAC (10.1/16 > 2.3.4.5)方向のソース・アドレス変換を設定することになります。
図3-6は、SUBSCRIBE/200OKトランザクションのUDPパケット・フローを説明しています。
UDPパケットのソース/宛先IPアドレスは青で示されるので注意してください。UAC > Oracle WebLogic Server SIP Container方向では、ロード・バランサは宛先IPアドレスを変換しますが、ソースIPアドレスは変換しません。Oracle WebLogic Server SIP Container > UAC方向では、ロード・バランサはソースIPアドレスを変換しますが、宛先IPアドレスは変換しません。
図3-6からのシーケンスの完全なメッセージ・トレース(IP/UDPヘッダーおよびSIPペイロードを含む)は、次の例3-6で示されます。
例3-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 Server SIP Containerが後でNOTIFYリクエストをUACへ送信する場合、図3-7で示されるシーケンスが発生します。
前のシーケンスのように、IPアドレス変換はソースIPアドレスのOracle WebLogic Server SIP Container > UAC方向、および宛先IPアドレスのUAC > Oracle WebLogic Server SIP Container方向で起こります。
この設定は、セッション状態情報を保持したり、SIPを認識できるようになるためにロード・バランサを必要としないので注意してください。図3-7からの完全なメッセージ・トレースは、次の例3-7で示されます。
例3-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>
|
注意: NATがソース(SNAT)および宛先のIPアドレスの両方で実行される場合、ロード・バランサが通常はリクエストの応答として送信される固有の宛先ポート番号の値に依存するため、構成は機能しません。そのポート番号値はRFC 3261によって記述されており、ロード・バランサのNAT要件との競合を示すViaヘッダーに由来する必要があります。RFC 3261では、SIPリクエストへのレスポンスは、リクエストの送信に使用されるIPアドレスへ送信される必要があります(3.9.3.2項「maddrベースの構成」で示されるように、maddrがViaで提示されない場合)。その結果、次の図3-8の手順3では、Oracle WebLogic Server SIP Containerは200回のOKレスポンスをロード・バランサの内部IPアドレス(10.1.3.4)およびポート5060番に送信します。そのため、このレスポンスは削除されます。 |
図3-8からの完全なメッセージ・トレースは、次の例3-8で示されます。
例3-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に着信します。
図3-9からの完全なメッセージ・トレースは、次の例3-9で示されます。
例3-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は、サーバーがViaではなくリクエストからレスポンスをUDPポート番号へ送信するようにクライアントがリクエストできるようにすることによって、SIPおよびNATの相互作用を向上します。SUBSCRIBEおよびNOTIFYの両方を正常に機能させるためには、UACとOracle WebLogic Server SIP Containerの両方がRFC 3581をサポートする必要があります。図3-10はSUBSCRIBEフローを示しています。
図3-10からの完全なメッセージ・トレースは、次の例3-10で示されます。
例3-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
図3-11はNOTIFYフローを示しています。
ソース・アドレスNATが両方向(UAS > Oracle WebLogic Server SIP ContainerおよびOracle WebLogic Server SIP Container > UA)で有効化される一方で、ロード・バランサは、リクエストの送信に使用されるのと同一のポート番号におけるレスポンスの受信に依存することによって、手順3で正常に宛先アドレスを識別できるので、注意してください。つまり、ロード・バランサは状態を維持することを暗示しています。
図3-11からの完全なメッセージ・トレースは、次の例3-11で示されます。
例3-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
