ヘッダーをスキップ
Oracle Communication and Mobility Server開発者ガイド
リリース10.1.3
E05480-02
  目次
目次		 索引
索引
戻る
戻る 		 次へ
次へ		  

3 SIPサーブレットの高度な構成

この章では、SIPサーブレットに関連する高度なトピックについて説明します。内容は次のとおりです。

appIdパラメータを使用したSIPアプリケーションのアドレスの設定

JSR 116では、SIPアプリケーションのアドレスを設定する方法は規定されていないため、OCMSではappId（アプリケーションID）と呼ばれるパラメータを組み込むことで仕様を拡張しています。このパラメータは、最上位のROUTEヘッダー（例3-1）のURI、またはリクエスト・メッセージのREQUEST URI（例3-2）にあります。OCMS SIPサーブレット・コンテナは、これら両方のフィールドでこのパラメータをチェックします。このパラメータにより、INVITE、MESSAGE、PUBLISH、REGISTERおよびSUBSCRIBEの各着信リクエストに応じて適切なアプリケーションが起動されるようになります。

OCMS SIPサーブレット・コンテナは、appIdパラメータを含まない着信リクエストを受信すると、Application Routerを起動してリクエストのROUTEヘッダーにアプリケーション・ルーティング情報を挿入します。


注意:

通常、Oracle Communicator以外のSIPクライアントによって生成されたリクエストでは、ROUTEおよびREQUEST URIのどちらのヘッダーにもappIdパラメータは含まれません。

OCMS SIPサーブレット・コンテナによるappIdパラメータの識別方法

OCMS SIPサーブレット・コンテナは、appIdパラメータに定義された値を着信リクエストに対して起動するアプリケーション名として解析します。この値は完全なアプリケーション名として、またはSipServletContainer MBean（『Oracle Communication and Mobility Server管理者ガイド』を参照）のApplicationAliases属性を使用して設定するアプリケーションの別名として定義できます。たとえば、OCMS SIPサーブレット・コンテナがappIdパラメータを含むリクエストを受信すると、コンテナは例3-1のpresenceなど、パラメータに設定された値を検索します。presenceというアプリケーションが見つからない場合、403レスポンス（「Forbidden」）が返されます。一方、appIdパラメータで定義されたアプリケーションが見つかった場合、第2章の「サーブレットのマッピング」で説明したmatchメソッドを使用して、このアプリケーションにリクエストの処理を要求します。適合するルールを持つサーブレットがアプリケーションにない場合、matchメソッドはnullを返し、403レスポンスが返されます。

リクエストにROUTEヘッダーが含まれない場合、コンテナはREQUEST URIに含まれるappIdをチェックします。

例3-1では、リクエストにROUTEヘッダーが存在します。OCMS SIPサーブレット・コンテナが自身のアドレスとしてIPアドレス192.168.0.100を認識するように構成されている場合、ROUTEヘッダーのappIdを使用してpresenceというアプリケーションを起動します。

例3-1 着信リクエストのROUTEヘッダーのappIdパラメータ

SUBSCRIBE sip:bob@example.com
To: .
From: .
Route: <sip:192.168.0.100:5060;appId=presence>

例3-2では、REQUEST URIにappIdが存在します。例3-1と同様、自身のアドレスとしてIPアドレス192.168.0.100を認識するように構成されている場合、OCMS SIPサーブレット・コンテナはREQUEST URIヘッダーのappIdを使用してアプリケーションpresenceを起動します。

例3-2 着信リクエストのREQUEST URIのappIdパラメータ

SUBSCRIBE sip:bob@example.com;appId=presence
To: .
From: .
Route: <sip:192.168.0.100:5060>

一部のインスタンスでは、SIPクライアントのアウトバウンド・プロキシが事前ロードされたルートではなく、リクエストの送信に使用されるアウトバウンド・プロキシへの接続である場合に、OCMS SIPサーブレット・コンテナが他のIPアドレスを対象とするリクエストを受信することがあります。OCMS SIPサーブレット・コンテナが考慮できるのは、自身を対象とするリクエストに含まれるappIdのみです。appIdパラメータで指定されたものと一致するアプリケーションをコンテナがホスティングする場合でも、リクエストを受け入れることはできません。これは、リクエストされたアプリケーションが別のIPアドレスに存在し、アプリケーションをリクエストしているユーザーがシステムに属していない可能性があるためです。

appIdパラメータの構成

appIdパラメータは、Application Router MBean（図3-1に示すocmsrouteloaderear）のSipUriList属性の一部として構成されます。この属性を使用して、アプリケーション・ルーティング順序を設定することで、INVITE、MESSAGE、PUBLISH、REGISTERおよびSUBSCRIBEの各着信リクエストに応じてOCMS SIPサーブレット・コンテナの動作を設定します。

図3-1 INVITEリクエストに対するアプリケーション・ルーティングの設定

図3-1の説明が続きます
「図3-1 INVITEリクエストに対するアプリケーション・ルーティングの設定」の説明

SipUriList属性は、URI、転送方法およびApplication Routerが着信リクエストのROUTEヘッダーに挿入するアプリケーションのappIdのカンマ区切りリストで構成されています。

デフォルトのリストにより、リクエストはProxy Registrarにルーティングされますが、このリストは次のように定義されます。

sip:<SIP Container IP Address>:<SIP port>;transport=TCP;lr;appId=proxyregistrar

次に例を示します。

sip:144.25.174.189:5060;transport=TCP;lr;appId=proxyregistrar

リクエスト・ルーティングは、この属性にリストされるアプリケーションの順序に応じて設定されます。たとえば、dialinというアプリケーションをINVITEリクエストの最初の宛先としてコールするには、次のようにdialinに関する情報を最初の項目としてリストに挿入します。

sip:144.25.174.189:5060;transport=TCP;lr;appId=dialin,sip:144.25.174.189:5060;       transport=TCP;lr;appId=proxyregistrar

注意:

Proxy Registrarは、必ずSIPUriList属性にリストされる最後の項目である必要があります。

SipUriList属性へのデプロイ済アプリケーションの追加

OCMS SIPサーブレット・コンテナにデプロイしたアプリケーションが着信リクエストに応じて起動されるようにするには、リクエスト関連のデプロイ済アプリケーションをすべてこのリストに追加する必要があります。appIdパラメータに定義するアプリケーション名（大文字と小文字が区別されます）は、デプロイ済アプリケーションの完全名またはアプリケーションの別名です。別名の場合、名前は、SIPサーブレット・コンテナMBeanのApplicationAliasesパラメータに設定したアプリケーションの別名と一致する必要があります。SIPサーブレット・コンテナMBeanおよびOCMS SIPサーブレット・コンテナにアプリケーションをデプロイする方法の詳細は、『Oracle Communication and Mobility Server管理者ガイド』を参照してください。

アプリケーション・セキュリティの構成

デプロイメント・ディスクリプタ・ファイルの<security-constraint>要素を使用して、アプリケーションのセキュリティを有効にします。セキュリティは、認証と承認を必要とするサーブレットに<security-constraint>要素を追加して、サーブレットごとに宣言します。

<proxy-authentication/>要素では、サーブレットの認証を定義します。サーブレットで認証が必要な場合、デフォルトの401レスポンス（「Unauthorized」）または407レスポンス（「Proxy Authentication Required」）のどちらかを要求できます。

セキュリティ制約には1つ以上のリソース・コレクション<resourcecollection>を入れることができます。それぞれが、サーブレットに認証および認証を必要とするSIPメソッドが必要であることを示します。

ユーザーは1つ以上のロールを持つことができます。まったくロールを持たなくてもかまいません。各セキュリティ制約では、承認制約<auth-constraint>を1つ設定できます。設定しなくてもかまいません。その承認制約には、認証されたユーザーを承認するロール名<role-name>を含めます。複数のロール名を含めることができます。また、含めなくてもかまいません。承認は、デプロイメント・ディスクリプタ内からだけでなく、サーブレット内からプログラムでチェックすることもできます。たとえば、SipServletRequestまたはSipServletResponseオブジェクトでisUserInRoleメソッドを使用します。

例3-3は、リクエストがINVITEまたはMESSAGEの場合に、MyServletに対して認証を必要とするセキュリティ制約を示しています。ロールに対する承認制約はありません。<proxy-authentication/>が設定されている場合、認証されていないユーザーはそのリクエストに対して407レスポンス（「Proxy Authentication Required」）を受け取ります。

例3-3 アプリケーション・セキュリティの構成

<security-constraint>
   <display-name>MyServlet Security Constraint</display-name>
   <resource-collection>
      <resource-name>MyServletResource</resource-name>
      <description>Securing MyServlet</description>
      <servlet-name>MyServlet</servlet-name>
      <sip-method>MESSAGE</sip-method>
      <sip-method>INVITE</sip-method>
   </resource-collection>
   <proxy-authentication/>
   <auth-constraint>
      <role-name>*</role-name>
   </auth-constraint>
</security-constraint>

例3-4に示すように、SIPクライアントがサーバーにREGISTERリクエストを送信すると、クライアントには401（「Unauthorized」）メッセージが返されます。認証に成功すると、<auth-constraint>で設定されたロール名に基づいてユーザーのロールがチェックされます。

例3-4 セキュリティ制約の構成

<security-constraint>
   <display-name>MyServlet Security Constraint</display-name>
   <resource-collection>
      <resource-name>MyServletResource</resource-name>
      <description>Securing MyServlet</description>
      <servlet-name>MyServlet</servlet-name>
      <sip-method>REGISTER</sip-method>
   </resource-collection>
   <auth-constraint>
      <role-name>Location Service</role-name>
   </auth-constraint>
</security-constraint>

ユーザーが認証後にREGISTERリクエストを再送信すると、ユーザーのロールに必要なLocation Serviceロールがあるかどうかがチェックされます。ユーザーが適切なロールを持っていない場合、403レスポンス（「Forbidden」）メッセージが送信されます。

  戻る
戻る 		 次へ
次へ
  目次
目次		 索引
索引