| Oracle Communication and Mobility Server管理者ガイド 10gリリース3（10.1.3） B50835-01 |
|
 戻る |
 次へ |
この章では、Oracle Communication and Mobility Server（OCMS）の概要について説明します。
Oracle Communication and Mobility Server 10.1.3.4のこのリリースには、次の拡張された機能や新機能があります。
現在では、OCMSのサブスクライバの永続性を確保するためにサポートされる主要データベースはOracle Databaseです。Oracle TimesTenはOCMS 10.1.3.4に付属しなくなりました。
新機能や改善点についての情報は、次のリンクから参照してください。
http://www.oracle.com/technology/products/ocms/otn_front.htm.
「サポートされるプロトコル、RFCおよび標準」も参照してください。
OCMS 10.1.3.4では、ネットワーク接続のオプションとしてTLSがサポートされています。
OCMS SIPサーブレット・コンテナでは、2つのモードでTLSをサポートしています。1つのモードではSIPコンテナがTLSサーバーとして機能し、もう1つのモードではSIPサーブレット・コンテナを構成して相互TLSが提供されます。この場合、コンテナはそのサーバー証明書を提供するだけではなく、クライアント証明書も必要とします。
User Dispatcherを使用すると、PresenceアプリケーションとXDMSアプリケーションのスケール変更を行えます。User Dispatcherは、SIP、HTTPおよびXCAPの各リクエストを（HTTPで）適切な宛先に一貫した基準でディスパッチするプロキシです。
WebサービスAPIについて、次の点が改良されています。
ParlayX 2.1 Presence Web Services APIで、非同期Webサービスなどを完全にサポートするようになりました。詳細は、第9章「OCMS Parlay X Presence Web Services」を参照してください。
SIPベースのParlayX 2.1 Messaging Web Services APIに新しいAPIが作成されました。詳細は、第10章「OCMS Parlay X Multimedia Messaging Web Services」を参照してください。
Contact Management APIの新しいAPI。これは、ユーザーの連絡先リストとプレゼンス・ルールの管理に役立つJAVAユーティリティAPIです。詳細は、OOCMSのインストールに付属しているjavadocを参照してください。このjavadocは、$ORACLE_HOME/sdp/api-docs/sdpcontactmanagement-10.1.3.4.0-javadoc.zipにあります。
Oracle Communication and Mobility Server（OCMS）は、SIPアプリケーションのデプロイおよび管理のためのキャリア品質のSIPアプリケーション環境です。標準のJava2 Enterprise Edition（J2EE）プラットフォーム上に構築されたOCMSは、SIPアプリケーションとサービスの簡単な統合を可能にする柔軟でスケーラブルな環境です。
次のようなアプリケーションを、SIPプラットフォームでデプロイできます。
音声およびビデオ・テレフォニ。通話転送や通話遮断などの通話管理サービスを含みます。
ユーザー・プレゼンス情報の公開とサブスクリプション。オンライン/オフライン・ステータス、通知、ユーザーのステータスへのアクセスの許可などです。
インスタント・メッセージング
Push to Talkアプリケーション。Push-to-Talk over Cellular（PoC）などです。
OCMSは、Presenceサーバー、プロキシとレジストラの複合サーバー、SIPサーバーなどの標準SIPアプリケーションを提供します。SIPプラットフォームに不可欠なこれらのアプリケーションはOCMSプラットフォームに自動的にインストールされるので、稼働までに必要な開発リソースと時間が減少します。
OCMSには、SIMPLEに準拠したプレゼンスとイベントの通知機能を提供する標準ベースのPresenceサーバーが備わっています。OCMS Presenceサーバーは、サブスクライバの負荷が大きいキャリアをサポートできるだけの堅牢性を備えながら、ISV、システム・インテグレータおよび統合プラットフォームと企業内Presenceサーバーを必要とする企業にも使用可能なソリューションです。
OCMSは次の機能を提供します。
デプロイ: SIPサーブレット・アプリケーションは、簡単にパッケージ化して、SIPサーブレット・コンテナとして機能するOracle Application Serverにデプロイできます。
構成と管理: Oracle Application Server管理コンソールを使用して、SIPアプリケーションおよびSIPサーバーとそのコンポーネントを管理できます。
認証とセキュリティ: ユーザー、ロールおよびポリシーのデータは、外部のRADIUSデータベースまたはOracle Identity Managementに格納できるので、OCMSは接続するユーザーをこのデータで認証できます。OCMSは、RFC 3261で指定されているように、ダイジェスト・ベースの認証でSIPトラフィックを保護します。さらに、P-Asserted-Identityヘッダーを使用して信頼できるホストを構成できます。
ロギングと監視: 包括的なロギング機能と、JMX MBeanとして公開されるメトリックを使用して、デプロイされたSIPアプリケーションを監視できます。
Oracle Communication and Mobility Serverのアーキテクチャは、3つのレイヤーで構成されています。
プロキシ・レイヤーには、IPロード・バランサとOCMS Edge Proxyサーバーが含まれます。IPロード・バランサは、SIPリクエストが送信される一意なパブリック・アドレスを提供します。SIPリクエストを、IPロード・バランサはOCMS Edge Proxyサーバーまたは直接OCMS SIPサーバーに配信します。
IPロード・バランサはSIP対応ではないので、送信者や受信者など、自分が転送しているトラフィックの内容を認識しません。IPロード・バランサは、個別のサーバーの可用性に基づいて、OCMSノードにリクエストを分散させます。これは、クラスタ環境では不可欠の機能で、特にノード障害の場合に重要です。ノードの障害が発生した場合、ロード・バランサは、障害が解決されるまで、残りのノードにトラフィックを再分配します。
OCMS Edge Proxyは、SIPリクエストを特定のOCMS SIPサーバーにプロキシするSIPロード・バランサです。Edge ProxyはセッションとSIPサーバーの間の論理的な経路を形成し、特定のセッションから送信されたSIPトラフィックが常に同じサーバーで処理されるようにします。SIPクライアントの数が増えたときには、Edge Proxyサーバーを追加して、高いスケーラビリティと効率性を備えたSIPクライアントの処理を提供できます。
アプリケーション・レイヤーは、通常、OCMS SIPサーバー・ノードのクラスタで構成されます。アプリケーション・レイヤーにより、SIPクライアントは短いレスポンス時間と高いスループットでSIPリクエストを処理します。アプリケーション・レイヤーが処理するトランザクションの数が増えたときは、OCMS SIPサーバー・ノードを追加することで対応できます。セッション・データの高可用性を実現するには、フェイルオーバーしてもセッションが失われないようにセッション・データのレプリケーションを有効にできます。
図1-2は、OCMSの論理的なシステム・コンポーネントを示しています。
OCMSのコンポーネントは次のとおりです。
User Dispatcher（「User DispatcherでのスケーラブルなPresenceのデプロイメント」を参照）
サーブレットは、J2EEプラットフォームを使用するWebサーバー上で実行する動的なアプリケーションです。HTTPサーブレットAPIと同様に、SIPサーブレットAPI（JSR116）は、Javaサーブレットの機能を拡張したもので、基礎となっているネットワークに関係なく、SIPリクエストを受信し、SIPレスポンスを生成します。SIPアプリケーションは1つ以上のSIPサーブレットで構成され、SIPサーブレットは、デプロイメント・ディスクリプタとともにパッケージ化されて、J2EE SIPサーブレット・コンテナにデプロイされます。
両者は似ていますが、SIPサーブレットは次のような点がHTTPサーブレットと異なります。
SIPアプリケーションは、インテリジェントなリクエスト・ルーティング、および複数の宛先に対してであっても必要に応じてリクエストをプロキシする機能を備えています。
SIPはpeer-to-peerプロトコルであり、通常、そのエンドポイントはSIPリクエストを開始したりSIPリクエストに応答したりできます。
SIPサーブレット・アプリケーションは、特定のイベントに対して呼び出されるように登録できます。
HTTPサーブレットとは異なり、SIPサーブレットは非同期です。つまり、SIPサーブレット・アプリケーションは、SIPリクエストを受信すると、別のアクションを開始し、制御をSIPサーブレット・コンテナに戻して、後でリクエストに応答できます。
SIPサーブレット・アプリケーションは、複数のSIPサーブレットで構成されることがよくあります。
SIPサーブレットとHTTPサーブレットは同じ汎用サーブレット使用に基づいているので、両方の種類のサーブレットを簡単に1つのアプリケーションに統合できます。したがって、SIPサーブレットとHTTPサーブレットの両方で構成されているアプリケーションは、SIPトラフィックとHTTPトラフィックの両方を処理できます。
SIPサーブレット・コンテナはJ2EEアプリケーション・サーバーを拡張したもので、セキュリティ、同時実行性、ライフサイクル管理、トランザクション、デプロイなどのサービスを含むSIPアプリケーションに対するランタイム環境を提供します。JSR116に準拠したSIPサーブレット・コンテナは、トランスポート・プロトコル、IPアドレス、ポート番号の組合せを使用して着信するSIPトラフィックをリスニングし、SIPのリクエストとレスポンスを送受信するためのネットワーク・サービスを提供します。
OCMS SIPサーブレット・コンテナは、OC4Jで動作するOracle Application Serverの既存のインスタンスにインストールできます。または、OCMS SIPサーブレット・コンテナをOC4Jの専用のスタンドアロン・インスタンスで実行することもできます。
標準的なOCMS SIPサーブレット・コンテナは、J2EEコンテナとしてOC4Jを使用するOracle Application Serverインスタンスと、サーバーを監視するためのOracle Process Manager and Notification Server（OPMN）で構成されます。現在、OCMSは、この構成でのみ高可用性デプロイをサポートします。
SIPサーブレット・コンテナは、サーバーの起動時に構成されます。SIPサーブレット・アプリケーションがSIPサーブレット・コンテナにデプロイされると、デプロイメント・ディスクリプタを使用してサーブレットが構成され、サーブレット・コンテキストが作成されます。SIPアプリケーションのリスナーとサーブレットがインスタンス化され、サーブレットがサーブレット構成で初期化されます。
SIPサーブレット・コンテナは、最初の着信リクエストを受信すると、一連のルールを処理して、リクエストを正しいSIPサーブレットに送信します。SIPサーブレットは、リクエストを受信すると、リクエストを新しい宛先にプロキシするか、別のサーブレットにディスパッチするか、またはレスポンスを送信する必要があります。
最初の着信SIPリクエストに対するロード・バランサとして機能します。
セッション内の以降のSIPリクエストについて、SIPサーバーにアフィニティとフェイルオーバーを提供します。
OCMSアプリケーション・サーバーのルーティング・テーブルを動的に作成し、クラスタ内のOCMSアプリケーション・サーバーの状態を管理します。
Edge Proxyは、SIP非対応のロード・バランサとOCMSクラスタの間で使用されると、着信したSIPトラフィックをOCMS SIPアプリケーション・サーバー間に分散させます。専用のサーバー上で稼働するスタンドアロンのJavaアプリケーションの場合は、Edge Proxyは、セッションの期間中、クライアントとSIPアプリケーション・サーバーの間にアフィニティを確立します。つまり、セッションの期間中は、特定のクライアントからのトラフィックを常に同じOCMS SIPアプリケーション・サーバーが処理し、クライアントとサーバーの間にパスが作成されます。
高可用性の環境では、複数のEdge Proxyサーバーをデプロイできます。このようなシナリオでは、ロード・バランサが着信トラフィックをEdge Proxyサーバー間に分配します。同時に、Edge Proxyサーバーが、OCMS SIPアプリケーション・サーバーのクラスタに接続しているサブスクライバの大きな負荷を処理できます。
図1-7は、クラスタ化されたOCMS環境において、2台のEdge ProxyサーバーがSIP接続の負荷を減らす仕組みを示しています。サード・パーティ製のロード・バランサが、クライアントがリクエストを送信できる単一の仮想IPアドレスを提供し、SIPリクエストを複数のEdge Proxyサーバーに分配します。高可用性を実現するために、Edge Proxyサーバーを重複させることができます。いずれかのEdge Proxyに障害が発生すると、障害が発生したノードのワークロードを別のEdge Proxyが引き継ぎます。OCMSサーバー・ノードの数を増やす場合、システム内で確立される追加の接続を処理するために、トポロジにEdge Proxyサーバーをさらに追加する必要がある場合があります。
OCMS Proxy Registrarは、SIPプロキシ・サーバーとレジストラの機能を結合します。主要なタスクは次のとおりです。
サブスクライバの登録。Proxy Registrarは、サブスクライバのアドレスを登録し、それをサブスクライバの端末の実際のアドレスにマップします。Proxy Registrarは、サブスクライバの連絡先情報をロケーション・サービスのデータ・ストアに格納し、このデータを使用して、SIPアプリケーション・サーバーとサブスクライバの間にパスを作成します。
リクエストの前方へのプロキシ。SIPリクエストを受信すると、Proxy Registrarは、ロケーション検索サービスまたはENUM（TElephone NUmber Mapping）サービスを使用して、サブスクライバの現在の連絡先情報を検索します。Proxy Registrarは、リクエストの宛先URIを、どちらかの検索サービスから返された現在の正しいSIPアドレスに置き換えて、リクエストをこの宛先にプロキシします。
ロケーション検索サービスは、RFC3261で定義されているように、すべてのサブスクライバの登録情報を格納します。Proxy Registrarは、この情報を使用して、常に正しいクライアントのサブスクライバに到達します。たとえば、あるサブスクライバは自宅または職場のクライアントを使用してOCMSに接続する場合があります。
登録データは、Oracle Databaseに格納されます。Proxy Registrarは、ロケーション・サービスを使用してサブスクライバの現在の実際の連絡先情報を検索し、リクエストをそのURLにプロキシします。このようにして、Proxy Registrarは、ユーザーとノードの間に直接的で再利用可能な接続を作成します。Proxy Registrarは、この接続を使用して、以降のリクエストを正しい宛先にルーティングします。一方、クライアントは、状態を定期的に更新し、ロケーション・サービスのデータを最新の状態に保つ必要があります。
着信したSIPリクエストの宛先URIに電話のURIが含まれる場合、Proxy Registrarは、ENUM（TElephone NUmber Mapping）サービスを使用して、電話番号をSIPアドレスに変換する必要があります。OCMSが提供するENUMサービスは、構成されているDNSサーバーを使用して電話番号を検索し、それをSIPアドレスに変換します。ENUMサービスは、電話番号の宛先URIを変換されたSIPアドレスに置き換えて、リクエストを宛先にプロキシします。
ENUM検索サービスの主なタスクは次のとおりです。
着信したリクエストのURIに含まれる電話の宛先を、ホスト名に変換します。次に例を示します。
$ORIGIN 2.4.2.4.5.5.5.5.1.4.1.e164.arpa.
変換されたホスト名を構成済のDNSサーバーで検索します。DNSサーバーは、電話番号の検索に基づいて、一致するSIPアドレスを返します。
IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:4242@555telco.example.com!"
電話番号のURIを、適切に書式設定されたSIPアドレスに置き換えます。
リクエストをSIPアドレスにプロキシします。
OCMSには、RFC 2778、3265、3856、3857、3858、3859、3863、3903およびOMA Presence Enabler 1.0に基づく専用のPresenceサーバーが組み込まれています。OCMS Presenceサーバーは、プレゼンス情報の登録、保管および検索を処理します。
プレゼンスは、ユーザーの状況と通信の意思を表しています。Presenceサーバーは、ユーザーがオンラインかオフラインか、そしてユーザーがアイドル状態か接続可能かを示すことができます。Presenceサーバーを使用することで、ユーザーはインスタント・メッセージングのハンドル、携帯電話番号、音声およびビデオ機能などの、連絡先に関する詳細を公開できます。
いくつかのロールがプレゼンスのコンテキストで定義されています。
プレゼンティティ: Presenceサーバーにプレゼンス情報を提供するユーザー・エンティティです。プレゼンティティは、職場のコンピュータ、自宅のコンピュータ、モバイル・デバイスなど、複数のPUAを持つことができます。
プレゼンス・ユーザー・エージェント（PUA）: インスタント・メッセージング・アプリケーション（Oracle Communicator）やモバイル・デバイスなど、プレゼンス情報を提供するデバイスです。PUAは、プレゼンティティの情報をPresenceサーバーに提供します。
ウォッチャ: Presenceサーバーにプレゼンスまたはウォッチャの情報を要求します。ウォッチャには、フェッチャとサブスクライバの2種類があります。
Presenceサーバーには次のような機能があります。
プレゼンティティ用のプレゼンス・ドキュメントにイベント状態を結合します。
ウォッチャからのSUBSCRIBEリクエストを受け取って、特定のプレゼンティティのプレゼンス・データに対するサブスクリプションを作成します。
通知者として機能し、NOTIFYリクエストを生成して、サブスクライブされているプレゼンティティの状態をサブスクライバに通知します。
図1-9で示されているプレゼンティティAliceは、3つのプレゼンス・ユーザー・エージェント（PUA）を持っています。これらのPUAのいずれかで稼働するクライアントが、OCMS PresenceサーバーにAliceのプレゼンスを公開します。一方、ウォッチャのBobとCathyは、Aliceのプレゼンス情報のサブスクライブを要求します。
BobとCathyが実行するクライアントは、Aliceのプレゼンスに対するSUBSCRIBEリクエストをPresenceサーバーに送信します。PresenceサーバーはAliceのプレゼンス・ポリシー・ドキュメントを調べて、BobとCathyにAliceのプレゼンスのサブスクライブを許可するかどうかを判断します。許可できる場合は、PresenceサーバーはAliceの現在のプレゼンス状態に関する情報を含むNOTIFYメッセージを送信します。Aliceのプレゼンス状態が変化するたびに、PresenceサーバーはBobとCathyのクライアントにNOTIFYメッセージを送信して、状態の変化を通知します。
次の図は、Presenceサーバーがプレゼンス情報を管理する方法を示しています。
ユーザーのプレゼンス情報は変化する場合があります。たとえば、ユーザーが、モバイル・デバイスやラップトップなどの異なるPUAを使用したり、アイドル状態や不在になった場合などです。Presenceサーバーは、このようなデータの変化を次のような方法で処理します。
プレゼンティティは、各ウォッチャが使用できる情報を指定したポリシー・ドキュメントをアップロードします。たとえば、自分がオンラインかどうかを特定のウォッチャのみが確認できるようにする場合などがあります。
各PUAは新しいプレゼンス情報をPresenceサーバーに送信し、SIP PUBLISHリクエストを発行します。プレゼンス情報はプレゼンス・ドキュメントの形式で送信されます。
Presenceサーバーは、プレゼンス・ドキュメントを受け取り、プレゼンス・ドキュメントのマージに関するルールを指定しているコンポジション・ポリシーを使用して、データを単一のドキュメントにマージします。
統合されたドキュメントは、プレゼンティティが手順1でPresenceサーバーにアップロードしたプライバシ・ポリシーを使用してフィルタ処理されます。このフィルタ処理により、プレゼンティティが特定のウォッチャに提供しない情報が除去されます。
Presenceサーバーは、プレゼンス・ドキュメントを含むNOTIFYリクエストをウォッチャに送信します。
OCMS Application Routerは、着信したSIPリクエストを正しいアプリケーションにルーティングするSIPアプリケーションです。Application Routerは、処理する各SIPリクエストにルート・ヘッダーを設定することで、リクエストをルーティングします。それぞれが異なる宛先URIを表す複数のルート・ヘッダーを、1つのリクエストに設定できます。SIPリクエストは、一連の宛先URIを通過して送信されるか、または最初の宛先に到着した時点で新しいURIにプロキシされます。
Application Routerは、通常、SIPリクエストをProxy RegistrarまたはPresenceサーバーにルーティングします。1つのApplication Routerに、任意の数のアプリケーションURIを追加して構成できます。
Application Routerは、標準と増分の2つのモードで動作します。
Application Routerは、着信したSIPリクエストのヘッダーに任意の数の宛先URIつまりルートを埋め込みます。SIPリクエストは、リクエストが使用されるまで、このURIのチェーンをたどります。URIの順序は、各ルートに割り当てられる追加のエイリアスによって決まります（uri.1、uri.2など）。
Application Routerは、各ルートとともにApplication Routerに戻るルートを、着信したSIPリクエストに増分的に埋め込みます。SIPリクエストは、最初の宛先に送信された後、Application Routerに戻ります。Application Routerは、SIPリクエストの宛先URIを調べ、結果は次の2つのどちらかになります。
リクエストが送信されたアプリケーションによって宛先URIが変更されている場合は、Application Routerは新しいURIにSIPリクエストをプロキシします。
宛先URIが変化していない場合は、Application Routerは2番目のルートをSIPリクエストのヘッダーに埋め込んで、リクエストを送信します。この場合も、SIPリクエストは2番目の宛先に到着した後にApplication Routerに戻ります。Application Routerは、再びSIPリクエストを新しいURIにプロキシするか、または3番目のルートをSIPリクエストのヘッダーに埋め込むかを判定する必要があります。
たとえば、次の図に示すように、Application RouterがSIPリクエストに宛先uri.1、uri.2およびuri.3を埋め込むものとします。SIPリクエストは最初にuri.1に送信されます。アプリケーション1がSIPリクエストの宛先URIを変更すると、Application Routerはリクエストを新しいURIつまりアプリケーションxにルーティングします（図1-12を参照）。宛先URIが変更されていない場合は、Application Routerはルート・ヘッダーに構成されている次のURIつまりuri.2にリクエストをルーティングします。
ここでも、アプリケーション2がSIPリクエストの宛先URIを変更する場合があります。その場合は、SIPリクエストはアプリケーションyにルーティングされます（図1-12を参照）。そうでない場合は、Application RouterはSIPリクエストをuri.3にルーティングします。以下同様です。
Application Routerは、たとえばコール・スクリーニング・アプリケーションと組み合せて使用できます。このシナリオでは、Application Routerは標準モードで動作し、ルート・ヘッダーにはコール・スクリーニング・アプリケーションに対するものと、OCMS Proxy Registrarに対するものの2つの宛先URIが構成されています。
着信したSIPリクエストはApplication Routerによってインターセプトされます。Application Routerはコール・スクリーニング・アプリケーションのURIとProxy RegistrarのURIの両方を、SIPリクエストのルート・ヘッダーに埋め込みます。SIPリクエストはコール・スクリーニング・アプリケーションに渡されて、そこでリクエストを指定されているユーザーへのコールにつなぐかどうかが判定されます。
コール・スクリーニング・アプリケーションがコールを受け付けた場合は、SIPリクエストはProxy Registrarに送られて、そこから正しい宛先に転送されます。
コール・スクリーニング・アプリケーションがコールを拒否する場合は、「403 Forbidden」などのエラー・メッセージで応答し、SIPリクエストを停止してルーティング・チェーンを切断します。
Application Routerは、たとえば自動転送アプリケーションのコンテキストで使用できます。自動転送アプリケーションは、通常、SIPリクエストの宛先URIを変更してコールを転送します。たとえば、自動転送アプリケーションは、宛先URIをボイスメール・サーバーのURIなどに変更します。
これを行うためには、増分モードのApplication Routerを使用してSIPリクエストをインターセプトし、リクエストをプロキシします。SIPリクエストはApplication Routerに送信されます。Application Routerは、SIPリクエストのヘッダーに自分自身への戻りルートを設定して、自動転送アプリケーションにリクエストを転送します。自動転送アプリケーションは、SIPリクエストをボイスメール・サーバーに送信するかどうかを判定し、それに従ってSIPリクエストの宛先URLを変更します。SIPリクエストの宛先URIが変更された場合、Application Routerに戻ったSIPリクエストは、自動転送アプリケーションによって決定された宛先にプロキシされます。
Application Routerに戻ったSIPリクエストの宛先URIが自動転送アプリケーションによって変更されていない場合は、Application Routerは、Application Routerの設定で構成されている次のアプリケーションにSIPリクエストを送信します。
OCMS Subscriber Data Servicesは、ユーザー認証データ、ユーザー、ロール、ポリシー・データおよびユーザー・ロケーション・データを格納します。拡張された高可用性の構成では、共有データベースにより、すべてのOCMS SIPアプリケーション・サーバーが格納されているデータにアクセスできます。
次のデータが格納されます。
認証および認可データは、OCMSに対するアクセス制御を構成する基本的なフレームワークを提供します。認証および認可データは、RADIUSサーバーまたはOracle Identity Managementに格納できます。
ユーザー・データベースは、サブスクライバの認証に使用されるプライベート・サブスクライバIDを格納します。Proxy Registrarは、ユーザー・データベースに格納されているプライベート・サブスクライバIDと、SIPリクエストおよびレスポンスのパブリック・サブスクライバ・アドレスを対応させることで、ユーザーを認証します。ユーザー・データは、Oracle Identity Managementに格納されます。
