| Oracle Communication and Mobility Server管理者ガイド 10gリリース3（10.1.3） B50835-01 |
|
 戻る |
 次へ |
この章では、Oracle 10g Enterprise Application Server Controlを使用してOCMS SIPサーバーを管理する方法について説明します。
Oracle SIPサーバーは、Oracle 10g Enterprise Manager Application Server Controlコンソール（図3-1）を使用して管理するOC4Jコンテナです。
図3-1 Oracle 10g Enterprise Manager Application Server Control
アプリケーションの起動、停止、再起動、デプロイ、アンデプロイおよび再デプロイといったApplication Server Controlの標準的な機能に加えて、Application Server ControlのMBeanブラウザを使用すると、OCMSコンポーネントの構成と管理を行うことができます。OCMS MBean（マネージドBean）の属性を構成することで、管理タスクを実行し、OCMS SIPサーバー自体の基本構成（ポート、IP、ホスト・アドレス）を設定できます。さらに、OCMS MBeanを使用するとプレゼンスを構成して管理できます。
Application Sever Controlを使用すると、OCMS SIPサーバーを停止および再起動できます。他のOC4Jコンテナと同様に、OCMS SIPサーバーは、「ホーム」ページの「停止」ボタンと「再起動」ボタンを使用して停止および再起動できます（図3-1）。これらのボタンは、OC4Jインスタンス全体を制御します。OC4Jを停止または再起動すると、OCMS SIPサーブレット・コンテナおよびそこにデプロイされているアプリケーションも停止または再起動します。
スタンドアロン・モードでOCMSをインストールした場合、ORACLE_HOME/sdp/binにある起動および停止スクリプトをコマンドラインから呼び出すことができます。
startocms
または
stopocms
また、opmnctlまたはadmin_client.jarコマンドライン・ユーティリティを使用して、OC4Jまたはそのアプリケーションを停止、起動または再起動することもできます。
opmnctlを使用して、Oracle Application Serverのローカル・インスタンス上のOC4Jを含むすべてのOPMN管理プロセスを停止するには、次のようにします。
opmnctl stopall
opmnctlを使用して、Oracle Application Serverローカル・インスタンス上のOCMSのOC4Jインスタンスを停止するには、次のようにします。
opmnctl stopproc process-type=ocms
opmnctlを使用して、Oracle Application Serverのローカル・インスタンス上のOC4Jを含むすべてのOPMN管理プロセスを起動するには、次のようにします。
cd ORACLE_HOME/opmn/bin opmnctl startall
opmnctlを使用して、Oracle Application Serverローカル・インスタンス上のOCMSのOC4Jインスタンスを再起動するには、次のようにします。
cd ORACLE_HOME/opmn/bin opmnctl restartproc process-type=ocms
admin_client.jarを使用して、特定のOC4Jインスタンスまたはクラスタ全体のアプリケーションとその子アプリケーションを起動、停止または再起動するには、次の構文を使用します。
java -jar admin_client.jar uri adminId adminPassword -start|-stop appName
詳細は、『Oracle Application Server管理者ガイド』を参照してください。
「アプリケーション」ページ（図3-2）の「停止」、「起動」および「再起動」ボタンは、選択したSIPサーブレット・アプリケーションの実行状態を制御します。
|
注意: SIPコンテナ・アプリケーションに対する変更は、OC4Jを再起動しても保持されます。ロギングに対する変更は更新しても保持されます。 |
Application Server ControlコンソールのMBeanブラウザ（図3-3）を使用すると、MBeanを表示および構成できます。MBean（マネージドBean）は、分散環境内にあるアプリケーション、サービス、コンポーネントまたはデバイスなどのJMXで管理可能なリソースを表すJavaオブジェクトです。MBeanは、一連の属性と操作を含む管理インタフェースを公開します。このインタフェースは、MBeanインスタンスのライフサイクルの間、変化しません。MBeanは、定義されているイベントが発生したときには通知を送信することもできます。
MBeanの属性を使用すると、OCMS SIPサーバーを構成できます。
MBeanの管理については、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
Application Server ControlコンソールのMBeanブラウザを使用すると、システムMBeanとアプリケーション定義MBeanの両方を、表示、構成およびデプロイできます。
システムMBeanブラウザから、JSR 116に準拠するOCMS SIPサーブレット・コンテナに関連するMBeanにアクセスします。詳細は、「OCMS MBeanの管理」を参照してください。
使用できるシステムMBeanを表示するため、MBeanブラウザはOC4Jで稼働しているMBeanサーバーにアクセスします。
SIPアプリケーションに基づくMBeanは、システムMBeanブラウザには表示されず、それらを登録したアプリケーションのコンテキストで表示されます。たとえば、図3-3では、Subscriber Data Servicesアプリケーションによって登録されたMBeanが示されています。
|
注意: MBeanは、管理対象のアプリケーションとともにパッケージ化されます。 |
システムMBeanブラウザを使用すると、SIPサーブレット・コンテナMBeanを参照できます（図3-3）。システムMBeanブラウザにアクセスするには、次のようにします。
SIPサーバー・インスタンスのOC4Jホーム・ページに移動します。
「管理」をクリックします。「管理」ページが開き、使用可能なタスクが表示されます。
必要な場合は、タスク・リストの「JMX」セクションを展開し、「システムMBeanブラウザ」を表示します。
表の「システムMBeanブラウザ」行の「タスクに移動」アイコンをクリックします。「システムMBeanブラウザ」が開き、使用できるMBeanがツリー・ビューに表示されます。ツリー・コントロールでMBeanを選択して、属性の表示や編集、操作の呼び出し、通知サブスクリプションの管理などを行うことができます。MBeanのパラメータに対する変更をコミットするには、「適用」をクリックします。
|
ヒント: MBeanを探すには、「検索」機能を使用します。 |
選択したアプリケーションのMBeanを表示するには、次のようにします。
SIPサーバーのOC4Jホーム・ページで、「アプリケーション」をクリックします。アプリケーションのリストが表示されます。
選択したアプリケーションの「アプリケーション定義のMBeans」をクリックします。「アプリケーションMBean」ページが表示されます。そのアプリケーションに登録されているMBeanが、ツリー・ビューに表示されます。このツリー・コントロールでMBeanを選択して、属性、操作、統計情報および通知を表示できます。
MBeanの属性に対する変更をコミットするには、「適用」をクリックします。
ここでは、次のシステムMBean（表3-1のリスト）の構成パラメータについて説明します。
表3-1 SIPサーブレット・コンテナMBean
| タスク | MBean名 |
|---|---|
|
次のタスクがあります。
|
|
|
ログ出力コンポーネント（CUSTOMER、BADMSG、TRAFFIC、CONFIG、TIMER、STATISTICS、FORMATおよびAPPLICATION）のログ・レベルの設定。詳細は、第12章「ロギング・システムの構成」を参照してください。 |
|
|
クライアントによるNAT（Network Address Translating）エンティティの横断を可能にするバインディングの設定。 |
|
|
システム・キューの現在のステータスの表示。 |
|
|
メモリー使用量、アプリケーション・キュー使用量、ネットワーク・キュー使用量またはSIPセッション・テーブル使用量の容量しきい値に達したときのオーバーロード・アクションの設定。 |
|
|
OC4Jクラスタのデフォルト・タイムアウトの設定。 |
|
SIPサーブレット・コンテナは、SIPアプリケーションに実行環境を提供するスタンドアロンのJavaプロセスです。SIPサーブレット・コンテナMBean（SipServletContainer）が公開する属性を使用すると、OCMSのインストール時に設定された値（表3-2のリスト）を変更できます。インストール時のこれらの属性に対する値の設定の詳細は、Oracle Communication and Mobility Serverのインストレーション・ガイドを参照してください。
表3-2 OCMSのインストールで設定される値
| 値 | SIPサーブレット・コンテナ属性 |
|---|---|
|
SIPコンテナのIPアドレス |
IPAddress |
|
SIPコンテナが使用するトラフィック・ポート |
SIPPort |
|
クライアント・リクエストを受信するプロキシ |
EdgeProxy |
|
認証に使用されるSIPサーバーのドメイン（ホスト名）とSIPレルム |
DomainsandRealms |
表3-3では、SIPサーブレット・コンテナMBeanの属性について説明します。次の属性の値を入力する場合の形式はsip:host:port;transport=tcp|udpですが、通常は、入力する必要があるのはhostの値のみです。他の値はあらかじめ設定されています。
表3-3 SIPサーブレット・コンテナの属性
| 属性 | 値 |
|---|---|
|
ApplicationAliases |
アプリケーションの短い名前。詳細は、「アプリケーションの別名の設定」を参照してください。 |
|
Contact |
ユーザー・エージェント・クライアント（UAC）として機能するアプリケーションによってSIPリクエストに埋め込まれるContactヘッダーで使用されるホスト、ポートおよびトランスポート。この値はSIP URI形式で入力します。 この連絡先情報は、SIPサーバーが応答できるアドレスを提供します。 |
|
DefaultApplications |
リクエストに一致するアプリケーションがない場合に起動されるアプリケーションのカンマ区切りリスト。デフォルトでは、Application Routerがデフォルト・アプリケーションとして設定されます。複数のアプリケーションがSIPコンテナにデプロイされている場合は、デフォルト・アプリケーションとしてアプリケーション・ディスパッチャもデプロイする必要があります。アプリケーション・ディスパッチャ（OCMSではApplication Router）は、他のアプリケーションを直接アドレス指定して着信リクエストをルーティングします。詳細は、「Oracle Communication and Mobility Serverの概要」の「Application Router」を参照してください。 デフォルト・アプリケーションが設定されていない場合は、コンテナはデフォルト・アプリケーションとして特定したすべてのSIPアプリケーションを指定します。デフォルト・アプリケーションおよびSIPコンテナがサーブレットを呼び出す方法の詳細は、『Oracle Communication and Mobility Server開発者ガイド』の「サーブレット・マッピング」を参照してください。 |
|
DeployedApplications |
デプロイされているアプリケーションの読取り専用リスト。 |
|
DistributableContact |
高可用性環境で、ユーザー・エージェント・クライアント（UAC）として機能する分散可能アプリケーションのContactヘッダーに配置されるホスト、ポートおよびトランスポート。 |
|
DistributableRecordRoute |
高可用性環境で、分散可能アプリケーションのRecordRouteヘッダーに配置されるホスト、ポートおよびトランスポート。この値は、次の形式のSIP URIとして入力します。
入力する必要があるのはホスト名のみです（ 高可用性の構成の場合は、次の形式でこのパラメータを構成します。
Edge ProxyとOCMSの間で任意の種類のトランスポートを使用できるようにするには、トランスポート方式を削除します。詳細は、「高可用性のためのOCMS SIPコンテナの構成」を参照してください。 |
|
DistributableVia |
高可用性環境で、分散可能アプリケーションのViaヘッダーで使用されるホスト、ポートおよびトランスポート。この値は、次の形式のSIP URIとして入力します。
入力する必要があるのはホスト名のみです（ |
|
DnsIpAddress |
コンテナが解決しようとするDNSを含むカンマ区切りリスト。SipURI、つまりsip:host:port;transport=tcpとして入力します。この場合、必須部分はhostのみです。たとえば、127.0.0.1:53;transport=udpとなります。ポートとトランスポートは、デフォルトで53とUDPに設定されています。空の文字列を使用すると、ローカル・ホスト・ファイルを考慮する、同期OSベースのリゾルバ（NAPTRまたはSRVはサポートしない）が有効になります。このモードは、システムのデモや開発目的で使用されます。 DNS解決の実行の詳細は、「RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers」を参照してください。DNS解決はSIPメッセージ処理のコンテキスト内で実行されるため、DNSのパフォーマンスに問題があると、待ち時間が長くなります。本番環境ではキャッシングDNSサーバーを使用して、パフォーマンスの潜在的な問題を最小限に抑えることをお薦めします。本番環境ではDNSを指定する必要があります。 |
|
DomainsAndRealms |
この属性は、Java認証済レルムに対するSIPドメインのマッピングを定義します。このマッピングを使用して、SIP認証の間に、SIPリクエストと適切な認証レルムとの間のチャレンジが動的に行われます。たとえば、voip.com/voipのドメイン/レルム・マッピングでは、SIPサーブレット・コンテナによるチャレンジに応えてvoipに対する認証を行うために、user@voip.comというSIP URIを持つユーザーが必要です。 ホストされている構成済ドメインと、認証に使用される対応するレルムのカンマ区切りリストを入力します。（SIPコンテナ自体ではなく）アプリケーションは、このようなホストされているドメインを使用して、404（ファイル未検出）メッセージを送信します。 |
|
DomainLoopDetection |
trueに設定すると（デフォルトの設定）、SIPコンテナは、サーバーから解決可能なホスト名を持つ宛先にリクエストが送信されるたびにチェックします。ホスト名がサーバー自身のリスニング・ポートの1つに解決される（つまり、サーバーが自分宛にリクエストを送信している）場合は、サーバーは解決されたホスト名と、DomainsandRealmsおよびRecordRouteヘッダー属性に設定されている構成を比較して検査します。ホスト名が一致しない場合は、リクエストをブロックし、482（ループ検出）のメッセージで応答します。これにより、サーバーがサーバーのIPアドレスを指す偽のDNS名を設定し、最上位ルート・ヘッダーに偽のホスト名を設定してリクエストを送信するのを防ぎます。SIPコンテナはホスト名を認識できないので、Routeヘッダーをポップせず、リクエストがループします。 |
|
IPAddress |
SIPサーブレット・コンテナがリスニングするIPアドレス。デフォルト値の0.0.0.0は、すべてのIPアドレスを指定します。本番環境の場合は、この値を実際のIPアドレスに変更します。 |
|
NeedClientAuth |
この属性をtrueに設定すると、相互TLSが有効になります。この場合、SIPサーブレット・コンテナは、TLSハンドシェイク時にサーバー証明書を提供するだけでなく、クライアント証明書も必要とします。デフォルト値のfalseを設定すると、クライアントとのTLSハンドシェイク時にサーバー証明書を提供することにより、SIPサーブレット・コンテナがTLSサーバーとして機能できます。この機能は、useTLSがtrueに設定されている場合のみ使用できます。このパラメータをtrueに設定すると、ほとんどのSIPクライアントはクライアント証明書を提供できないため、SIPクライアントと連動しません。ほとんどのSIPクライアント・アプリケーションは証明書を提供できませんが、プロキシ・サーバーなどのクライアントは提供できます。 |
|
NetworkThreadCount |
ネットワーク・トラフィックを処理するためにSIPコンテナが作成するネットワーク・スレッドの数。値は整数である必要があります。 |
|
Edge Proxy |
クライアント・リクエストを受信するプロキシ。このプロキシは事前にロードされたルートを追加します。たとえば、sip:my.host:5060;transport=tcpなどです。この設定は、サーバーに対する再利用可能なTCP接続をクライアントが維持するために必要です。この接続を保証するため、クライアントは、定期的なCRLF（復帰改行）の送信などのキープ・アライブ・アルゴリズムを実装できます。 クラスタ環境では、Edge Proxyまたは他のプロキシ・アプリケーションとの通信をサポートするため、各OCMSインスタンスにEdge Proxyを構成する必要があります。高可用性インストールの場合は、Edge Proxyの前にあるロード・バランサが使用する、Edge Proxyのアドレスまたは仮想ホスト名とポート・サービスをこの属性に設定する必要があります。この値の設定には、次の形式を使用します。
詳細は、「高可用性のためのOCMS SIPコンテナの構成」を参照してください。 |
|
RecordRoute |
分散不可能なアプリケーションのRecordRouteヘッダーで使用されるホスト、ポートおよびトランスポート。この値は、次の形式のSIP URIとして入力します。
入力する必要があるのはホスト名のみです（ 高可用性の構成の場合は、次の形式でこのパラメータを構成します。
Edge ProxyとOCMSの間で任意の種類のトランスポートを使用できるようにするには、トランスポート方式を削除します。詳細は、「高可用性のためのOCMS SIPコンテナの構成」を参照してください。 |
|
SIPPort |
SIPサーブレット・コンテナがトラフィックを受け入れるポート。デフォルト値は5060です。 |
|
SipServletCommanInterceptors |
SipServletインターセプタ・クラスのカンマ区切りリスト。インターセプタは |
|
SipServletOc4jInterceptors |
OC4Jに固有のSipServletインターセプタ・クラスのカンマ区切りリスト。インターセプタは |
|
StatisticsPeriodicity |
SIPサーブレット・コンテナ・モニターに表示される統計をSIPサーブレット・コンテナが記録する間隔（単位は分）。この属性を0に設定すると、ロギング処理が一時停止します。 |
|
TimerListenerOc4jInterceptors |
OC4J固有の |
|
TimerT1 |
ラウンドトリップの推定時間（秒単位）。この値は整数である必要があります。 |
|
TimerT2 |
非INVITEリクエストとINVITEレスポンスの最大間隔（単位は秒）。この値は整数である必要があります。 |
|
TimerT4 |
メッセージがネットワーク内に留まることのできる最大時間（単位は秒）。この値は整数である必要があります。 |
|
TlsKeyStore |
Sun社のJKSタイプのキーストアのファイル・パス。 |
|
TlsKeyStorePassword |
パスワードまたは間接パスワード。たとえば、jazn.com/oc4jadminは、レルムjazn.comのJAZNユーザーoc4jadminのパスワードがストアのロック解除に使用されることを示します。JAZNユーザーは、OC4Jでjazn.jarを起動して作成されます。 |
|
TlsTrustStore |
Sun社のJKSタイプの信頼できるストアのファイル・パス。 |
|
TlsTrustStorePassword |
パスワードまたは間接パスワード。たとえば、jazn.com/oc4jadminは、レルムjazn.comのJAZNユーザーoc4jadminのパスワードがストアのロック解除に使用されることを示します。JAZNユーザーは、OC4Jでjazn.jarを起動して作成されます。 |
|
Trusted Hosts |
RFC 3325に記述されている、信頼できるホストを表すIPアドレスのカンマ区切りリスト。たとえば、192.168.0.10, 192.168.0.11のように入力します。値フィールドをブランクのままにすると、信頼できるホストがないことを意味します。アスタリスク（*）を入力すると、すべてのIPアドレスが信頼できることを意味します。正規表現はサポートされていません。 |
|
UdptoTcpTriggerSize |
SIPサーブレット・コンテナが送信するリクエスト・メッセージに含まれるバイト数の最大値。リクエスト・メッセージがこのサイズに達すると、SIPサーブレット・コンテナは、UDPでなくTCPを使用してリクエストを転送します。リクエストのデフォルト値は1300バイトです。 |
|
UseStun |
STUNbisキープアライブ・トラフィックを使用する場合は、trueを選択します。 |
|
UseTCP |
SIPサーブレット・コンテナがTCPトラフィックをリスニングする場合はtrueを選択します。ネットワーク・フラグメンテーションの問題のため、トランスポート・プロトコルとしてはTCPを設定することをお薦めします。TCPが優先されるプロトコルであることを示すには、DNSにNAPTRレコードとSRVレコードを追加します。OCMSに接続するクライアントがNAPTRおよびSRVレコードを完全にサポートすることを確認してください。 |
|
UseTLS |
trueを選択すると、SIPサーブレット・コンテナはクライアントとのTLSハンドシェイク時にサーバー証明書を提供できまます。trueに設定すると、SIPサーブレット・コンテナはTLSポートでリスニングします。TlsKeystore、TlsKeyStorePassword、TlsTrustStoreおよびTlsTrustStorePasswordの各属性も構成してください。 |
|
UseUDP |
SIPサーブレット・コンテナがUDPトラフィックをリスニングする場合はtrueを選択します。 |
|
Via |
分散不可能なアプリケーションのVIAヘッダーで使用されるホスト、ポートおよびトランスポート。この値はSIP URI形式で入力します。 |
OCMS SIPサーブレット・コンテナのSIPアプリケーションは、基本的に解析されたsip.xmlファイルです。したがって、SIPアプリケーションには、解析されたすべてのサーブレット定義とともに、サーブレット・マッピング（つまりルール）およびリスナーとしての他のsip.xmlコンポーネントが含まれます。
第13章「アプリケーションのデプロイ」で説明されているように、SIPアプリケーションは通常、OC4JにデプロイされるEnterprise Archive（EAR）としてビルドされます。SIPアプリケーションがデプロイされると、アプリケーション・サーバーはsip.xmlを解析し、サーブレットとリスナーをインスタンス化します。また、アプリケーション・サーバーは、EARファイルのコンポーネントを結合して、デプロイ済アプリケーションの名前を作成します。このようにして生成された名前は長くなることがあるので、アプリケーションの別名を作成できます。デフォルト・アプリケーションを構成するときは、この短くてわかりやすいアプリケーション名を使用できます。この短い名前は、ルート・ヘッダーのURIパラメータまたはリクエストURIで使用できます。
たとえば、サーバーにデプロイされるプレゼンス・アプリケーションの名前は、presenceapplicationear-4.0.0-dev/eventnotificationssr-4.0.0-devなどとなる場合があります。ApplicationAliases属性を使用すると、presence=presenceapplicationear-4.0.0-dev/eventnotificationssr-4.0.0-devのようなキー-値ペアを入力して、このアプリケーションに短い名前を設定できます。キーは別名（presence）で、値はアプリケーションの実際の名前です。この別名は、アプリケーションの実際の名前に使用できます。
|
注意: ApplicationAliases属性に設定する値は、Application RouterのSlipperiest属性のappIdパラメータとも一致している必要があります。それにより、着信リクエストに適したアプリケーションをOCMS SIPサーブレット・コンテナが起動します。appIdパラメータでは、大文字と小文字が区別されます。 |
キーストアは、2つのカテゴリ（キー・エントリと信頼できる証明書エントリ）に分けられる公開鍵と秘密鍵のデータベースです。SIPサーブレット・コンテナは、Sun社のJKSタイプのキーストアと連動します（PKCS12はサポートされません）。JKSタイプのキーストアには、キー・エントリと信頼できる証明書エントリの両方が含まれる場合があります。1つのキーストア・ファイルではなく、2つの異なるファイルを使用すると、SIPサーブレット・コンテナの証明書とその他のエントリの証明をより明確に分けられます（これはSIPサーブレット・コンテナでもサポートされます）。
|
注意: キーストアの複数の秘密鍵エントリはサポートされません。SIPサーブレット・コンテナは、各ドメインにつき1つの証明書をサポートします。コンテナにキーストア・エントリのパスワードを入力するメカニズムはありません。 |
TLSを有効にするには、javaシステム・プロパティのuseTLSとneedClientAuth（オプション）を設定する必要があります。TlsKeystore、TlsKeyStorePassword、TlsTrustStoreおよびTlsTrustStorePasswordの各属性も構成してください。
useTLS属性を設定する場合、構成されたTLSポートでコンテナがリスニングして、TLSハンドシェイク時にサーバー証明書を提供することを示します。
needClientAuth属性を設定する場合、サーバーは通常どおりにそのサーバー証明書を提供しますが、クライアントからの証明書も必要とします。SIPクライアントは、通常クライアント証明書を提供できないため、これはOracle Communicator（および他のSIPクライアント）と連動しない設定になります。クライアントがプロキシ・サーバーの環境では、この設定を使用できます。
ロギング・システムとログ・レベルの構成については、第12章「ロギング・システムの構成」を参照してください。
OCMSは、STUN（Simple Traversal of User Datagram Protocol（UDP）Through Network Address Translators（NAT））サービスを実装します。RFC 3489で記述されているように、STUNを使用することで、NATの背後にあるSTUNクライアント（つまりルーターの背後のクライアント）は、NATの存在およびNATの種類を検出し、NATによって割り当てられるアドレス・バインディング（IPアドレスを含む）を認識できます。
STUNはクライアント/サーバー・プロトコルであり、STUNクライアントがサーバーにリクエスト（バインディング・リクエスト）を送信すると、サーバーはレスポンスを送信します。OCMSは、クライアントからのバインディング・リクエストの受信をサポートします。このリクエストは、UDP経由で送信され、NATの存在の検出と、生成されるパブリックIPアドレスとポート・マッピングの検出の両方に使用されます。STUNクライアントがSTUNサーバーにバインディング・リクエストを送信すると、STUNサーバーはリクエストのソースIPアドレスとポートを検査し、クライアントに返送するレスポンスにそれをコピーします。STUNクライアントは、バインディング・レスポンスを受信すると、パケット中のIPアドレスおよびポートと、バインディング・リクエストをSTUNサーバーに送信したときにバインドしたローカルIPアドレスおよびポートを比較します。
STUNサービスMBeanの属性（表3-4を参照）を使用することで、STUNサーバーのプライマリとセカンダリのIPアドレスおよびポートを設定できます。これらは、クライアントのバインディング・リクエストを受信するためにSTUNサーバーが使用する、RFC 3489で指定されている4つのアドレス-ポートの組合せを形成します。RFC 3489で指定されている組合せは次のとおりです。
A1, P1: プライマリ・アドレスとプライマリ・ポート
A2, P1: セカンダリ・アドレスとプライマリ・ポート
A1, P2: プライマリ・アドレスとセカンダリ・ポート
A2, P2: セカンダリ・アドレスとセカンダリ・ポート
通常、STUNサーバーのプライマリ・ポート（P1）は、UDPポート3478に設定されます。バインディング・レスポンスに含まれるCHANGED-ADDRESS属性のセカンダリ・アドレスとセカンダリ・ポートの値（A2, P2）を使用します。
表3-4 STUNService MBeanの属性
| 属性 | 値 |
|---|---|
|
Autostart |
trueに設定すると、OCMSの起動時にSTUNサーバーも自動的に起動します。 |
|
PrimaryAddress |
着信バインディング・リクエストをリスニングするプライマリSTUNアドレス。デフォルト値は127.0.0.1です。 |
|
PrimaryPort |
着信バインディング・リクエストをリスニングするプライマリSTUNポート。値はUDPポート3478で、これはRFC 3489で記述されているデフォルトのSTUNポートです。 |
|
SecondaryAddress |
着信バインディング・リクエストをリスニングするセカンダリSTUNアドレス。PrimaryAddressと同じ値にすることはできません。 |
|
SecondaryPort |
着信バインディング・リクエストをリスニングするセカンダリSTUNポート。デフォルト値はUDPポート3479です。 |
ここでは、次のSIPアプリケーションに登録されているMBeanで使用できる構成について説明します。
Presence（「PresenceおよびPresence Web Servicesの概要」を参照）
Subscriber Data Services（subscriberdataservices）は、OCMSユーザー・リポジトリに対する認証とセキュリティが必要なすべてのSIPアプリケーションの親アプリケーションです。たとえば、Application Router、Aggregation ProxyおよびProxy Registrarには、Subscriber Data Servicesが必要です。Proxy Registrarの場合は、ロケーション・サービスと、Proxy Registrarのレジストラ・コンポーネントが、Subscriber Data Servicesに依存します。Subscriber Data Servicesは、Oracle Internet Directory（OID）へのアクセスも提供します。詳細は、「セキュリティの概要」を参照してください。また、OCMSデプロイ用のユーザー・プロビジョニング・リポジトリとして、Oracle WebCenter Suiteで使用されるLDAPデータ・ストアであるOracle Internet Directory（OID）を使用する方法は、「ユーザー・リポジトリとしてのOracle Internet Directoryの構成」を参照してください。
アカウント・セキュリティ
Subscriber Data Servicesは、アカウント・ロックアウト・サービスおよびログイン失敗サービスのMBeanグループをとおしてアカウント・セキュリティを提供します。
アカウント・ロックアウト・グループには次のMBeanが含まれます。
AAサービス
AAサービスMBeanは、ログイン失敗サービスがアカウントをロックするために使用します。このMBeanは、MathFunctionモデルMBeanに依存します。AAサービスMBeanは、MathFunctionモデルMBeanを利用することで、現在のログイン試行失敗回数に基づいてアカウントの次のロック期間を計算します。
|
注意: アカウントのロックは、OC4Jを再起動しても維持されます。 |
表3-5では、AAサービスMBeanの属性について説明します。
表3-5 AAサービスMBeanの属性
| 属性 | 値 |
|---|---|
|
MathFunction |
現在のログイン試行失敗回数に基づいてアカウントの次のロック期間を計算するために使用する演算関数の種類。演算関数（ |
|
DefaultLockDuration |
演算関数が使用できない場合に使用するロック期間（秒）。デフォルト値は600です。 |
|
JNDIName |
AAサービスのJNDI名。この値は読取り専用です。 |
|
SecurityServiceName |
ユーザー・アカウントをロック解除するために使用されるサービス・オブジェクトにバインドされているJNDI名。この値は読取り専用です。 |
Constant（読取り専用）
現在のログイン試行失敗回数に基づいてアカウントの次のロック期間を計算するためにMathFunction MBeanが使用する定数関数。
Exponential
現在のログイン試行失敗回数に基づいてアカウントの次のロック期間を計算するためにMathFunction MBeanが使用する指数演算関数。
Linear
現在のログイン試行失敗回数に基づいてアカウントの次のロック期間を計算するためにMathFunction MBeanが使用する線形演算関数。
Subscriber Data Services MBeanの場合は、AAサービスとコマンド・サービスのみを構成できます。
CommandService MBeanの操作を使用すると、Oracle DatabaseにOCMSユーザーをプロビジョニングするために使用されるSapphire Shell（Sash）と同等の機能を実行できます。たとえば、アカウント管理用のコマンドのリストを表示するには、次のようにします。
「操作」タブをクリックします。getコマンドのリストが表示されます。
「returning a help String for a partial command」の「ヘルプ」をクリックします。help操作のパラメータが表示されます。
「値」フィールドにaccountと入力します。
|
ヒント: 「マルチライン・エディタを使用」をクリックして「値」フィールドを拡張すると、長いコマンド名を入力できます。 |
「起動操作」をクリックします。アカウント管理に関係するコマンドが表示されます（図3-6）。これらのコマンドは、Sashプロンプトでhelp accountと入力して表示されるものと同じです。詳細は、第11章「Sashでのユーザーのプロビジョニング」の「サブコマンドの表示」を参照してください。
使用できるすべてのコマンドのリスト（図3-7）を表示するには、「操作」タブで「listAllCommands」を選択し、表示される「listAllCommands」ページで「起動操作」をクリックします。Sashコマンドについては、「使用できるコマンドの表示」を参照してください。Sashを使用したユーザー管理の詳細は、「ユーザーの作成」を参照してください。
コマンド・サービスMBeanは、XDMS（XML Document Management Server）にユーザーをプロビジョニングできるようにするために、Presenceアプリケーション内にデプロイされます。「コマンド・サービス（XDMSプロビジョニング）」を参照してください。
Proxy Registrarは、RFC 3261で記述されているプロキシおよびレジストラの機能を実装するユーザー・エージェント・サーバー（UAS）です。このSIPエンティティはメッセージのルーターです。Proxy Registrarのレジストラ機能は、ユーザー・エージェント・クライアントからのREGISTERリクエストを処理し、ロケーション・サービスを使用して、ユーザーのAOR（address of record）と、CONTACTフィールドに設定されているユーザーのSIPまたはSIPS URIの間のバインディング（つまり関連付け）を格納します。AORのリクエストを受け取ると、プロキシ機能は、ロケーション・サービス検索を使用してマッピングされているURIを検索した後、この検索で取得したロケーション情報を使用してリクエストをプロキシします。表3-7では、Proxy Registrarの属性について説明します。
表3-7 Proxy Registrarの属性
| 属性 | 説明 |
|---|---|
|
CurrentRegDevices |
同時に登録されたデバイスの数を表示する、読取り専用の属性。 |
|
DefaultExpires |
クライアント自身が優先される値を指定しない場合に、REGISTERリクエストの有効期限の値を設定します。この属性のデフォルト値は3600秒です。 |
|
MaxExpires |
サーバーが受け入れるREGISTERリクエストの有効期限の最大値を設定します。クライアントはREGISTERリクエストで任意の有効期限値を要求できますが、サーバーは有効期限として受け付ける最大時間を設定できます。クライアントがMaxEpiresに設定されている値より長い時間を要求した場合、サーバーは、その特定のREGISTERリクエストに対する有効期限をMaxExpiresの値に設定します。 この属性のデフォルト値は7200秒です。 |
|
MinExpires |
サーバーが受け入れるREGISTERリクエストの有効期限の最小値を設定します。クライアントは任意の有効期限を要求できますが、REGISTERリクエストの有効期限に非常に小さい値を指定する可能性もあります。値が小さいとクライアントは登録情報を頻繁に更新する必要があり、ネットワークのトラフィックが増加します。この最小有効期限より小さい値をクライアントが要求した場合、サーバーは、RFC 3261に従って、そのREGISTERリクエストを受け付けず、423（間隔が短すぎる）のエラー・レスポンスで応答します。このレスポンス・メッセージでは許容される最低限の有効期限を指定し、その値はMinExpires属性に設定されています。サーバーは、有効期限を短くすることはできますが、長くすることはできません。 この属性のデフォルト値は60秒です。 |
|
SipRegAllowThirdParty |
Proxy Registrarがサード・パーティの登録を許可するかどうかを指定します。サード・パーティの登録では、リクエストを発行しているエンティティ（Fromヘッダーの値）が、提供されている連絡先情報が適用される登録対象のエンティティ（Toヘッダーの値）と異なります。この属性をtrueに設定すると、Proxy Registrarはサード・パーティの登録を許可します。false（デフォルト値）に設定すると、サード・パーティの登録は拒否されます（要求元は、403（禁止）のステータス・コードを受け取ります）。これは、常にfalseに設定されている読取り専用の属性です。 |
|
SipRegMaxUsers |
Proxy Registrarがサポートするユーザーの最大数を指定する、読取り専用の属性です。 |
OCMS SIPサーブレット・コンテナは、アプリケーションID（appId）パラメータが含まれない着信リクエストを受け取ると、Application Routerを起動します。Application Routerは、このパラメータが含まれるルーティング情報を着信リクエストのROUTEに挿入します。その結果、OCMS SIPサーブレット・コンテナは、適切なアプリケーションを正しい順序で起動し、着信リクエストINVITE、MESSAGE、PUBLISH、REGISTER、およびSUBSCRIBEに応答することができます。『Oracle Communication and Mobility Server開発者ガイド』に記載されているように、appIdパラメータはJSR-116に対するOCMS拡張であり、リクエストをアプリケーションにルーティングする際に使用されます。
Oracle Communicator以外のSIPクライアントによって生成されるリクエストには通常、ROUTEヘッダーまたはREQUEST URIヘッダーにappIdパラメータが含まれていません。そのため、着信リクエストのROUTEヘッダーにappIdパラメータが存在していると、OCMS SIPサーブレット・コンテナはリクエストを正しく処理します。Application Router MBean（図3-8のocmsrouteloaderear）では、アプリケーションのルーティング順序などのルート関連の条件を定義することにより、着信リクエストINVITE、MESSAGE、PUBLISH、REGISTER、およびSUBSCRIBEの宛先を構成できます。
表3-8では、INVITE、MESSAGE、PUBLISH、REGISTER、およびSUBSCRIBEリクエストのルーティングを構成するための属性について説明します。
表3-8 Application Routerの属性
| 属性 | 説明 |
|---|---|
|
IncrementalMode |
このブール値を使用すると、Application Routerの実行モードを選択できます。trueの場合は増分モードで、falseの場合は標準モードです。
|
|
RecordRoute |
trueに設定すると、レコード・ルーティングが有効になります。 |
|
RouteLoaderUri |
Application Routerへの戻りルートのURI。この値は、SIPサーブレット・コンテナのURIと同じである必要があります。通常、SIPサーブレット・コンテナは、Proxy RegistrarのURIを自分のURIとして認識するため、Proxy RegistrarのURIとして値を設定します。 |
|
SipUriList |
Application Routerが着信リクエストのROUTEヘッダーに挿入する、アプリケーションのURI、トランスポート方式および デフォルト・リスト（リクエストをProxy Registrarにルーティングする）は、次のような定義です。 sip:<SIP Container IP Address>:<SIP port>;transport=TCP;lr;appId=proxyregistrar 次に例を示します。
リクエストのルーティングは、この属性にリストされているアプリケーションの順序に従って設定されます。たとえば、dialinというアプリケーションを sip:144.25.174.189:5060;transport=TCP;lr;appId=dialin,sip:144.25.174.189:5060; transport=TCP;lr;appId=proxyregistrar OCMS SIPサーブレット・コンテナにデプロイするリクエスト関連アプリケーションが着信リクエストに対応して起動されるようにするには、デプロイするアプリケーションをこのリストに追加する必要があります。
|
SIPポートは、Enterprise Managerではなく、opmn.xmlファイルで設定します。ポートは、範囲ではなく、5060などの特定のポート番号を指定してください。
opmn.xmlで設定したSIPポートは、Enterprise Managerの「サーバー・プロパティ」ページで確認できます。このページでSIPポートを変更しないでください。SIPポートを変更しようとすると、opmn.xmlファイルのprotocol部分がsipからajpに変更され、SIPコンテナがデフォルトのポート5060で起動します。
