SIP アプリケーション開発者のためのランタイム考慮事項

Session Initiation Protocol (SIP) アプリケーションを開発する際は、製品の特定のランタイム動作を考慮する必要があります。

コンテナーが SIP 以外の URI スキームを受け入れる可能性がある

SIP コンテナーは、要求 Uniform Resource Indicator (URI) のスキームを認識しない場合でも、メッセージを拒否しません。これは、どの URI スキーマがアプリケーションで使用されているのかをコンテナーが知ることができないためです。 SIP エレメントは、sip または sips 以外のスキームを持つ要求 URI をサポートする場合があります。例えば、pres: スキームは、存在サーバーに対して特定の意味を持ちますが、コンテナーはこれを認識しません。 特定のスキームを受け入れるかリジェクトするかの判断は、アプリケーションによって異なります。 SIP エレメントは、使用可能なメカニズムを使用して、SIP 以外の URI を SIP URI、SIPS URI、または RFC 2806 [9] の tel URI スキームなどのその他のスキームに変換することがあります。

移行ユーザーの方へ 移行ユーザーの方へ: SIP アプリケーションがバージョン 6.1 の Transport Layer Security (TLS) で SIP URI に要求を送信すると、その要求 URI スキーマは「sip」から「sips」に変わります。現行バージョンでは、このスキームは変更されません。この新しい振る舞いは、アプリケーション・コードを変更することにより、以前の振る舞いに戻すことができます。「sips」URI では、この振る舞いはバージョン 6.1 から 7.0 以降にアップグレードしても同じままです。詳しくはインフォメーション・センターのトピック『事前マイグレーションの考慮事項 (Premigration considerations)』を参照してください。trns

複数コンテナー環境で要求を送信する

複数コンテナー環境 (SIP プロキシーと SIP コンテナー) では、アプリケーションが最初は外部に送信し、後で受信する要求を送信する場合、最も近くのロード・バランシング・エレメント (複数の SIP プロキシーの場合は IP スプレイヤー、SIP プロキシーが 1 つのみの場合は SIP プロキシー) のホストおよびポートを使用する必要があります。 アプリケーションが最も近くのエレメントの代わりにコンテナーのホスト名を使用した場合、要求は失敗イベントの中で失われる場合があります。

例えば、アプリケーションが自分自身に INVITE 要求を送信し、この要求がプッシュされた経路ヘッダーを通じて外部のアカウンティング・システムを通過する必要があるとします。 アプリケーションは、フェイルオーバーが実行されるように、INVITE 要求の URI を第一のエレメントのホストおよびポートに設定する必要があります。 要求はプッシュされた経路を通じてアカウンティング・システムに送付され、次に処理のために近くのロード・バランシング・エレメントに送り返されます。

セッション・リスナー・イベントを起動する

SipSessionListener イベントおよび SipApplicationSessionListener イベントは、アプリケーションが対応するセッション・オブジェクトを要求した場合のみ起動されます。 これは、アプリケーションで表 1に示されたメソッドを使用して行います。
表 1. セッション・リスナー・イベントを起動するメソッド.

セッション・リスナー・イベントを起動するメソッドは、次の表のとおりです。

Event メソッド
SipSessionListener getSession()
SipApplicationSessionListener getApplicationSession()

セッションの活動化と非活性化

この製品では、通常のオペレーションでセッションをあるサーバーから別のサーバーにマイグレーションすることはありません。 セッションのマイグレーションは、サーバーの障害の結果としてのみ発生します。 したがって、SipSessionActivationListener メソッドの非活性化コールバックが呼び出されることはありません。 ただし、この活動化コールバックは、障害によって強制的に別のサーバーにセッションがフェイルオーバーされる場合に呼び出されます。

外部リソース

SIP アプリケーションで、外部データベースに対する入出力やアクセス を集中的に行うと、数ミリ秒間ブロックされることがあります。 このようなリソースに対しては、できる限り、非同期 API を使用してください。ブロックされた SIP アプリケーションは、ストレスによって、要求タイムアウトや再送信を引き起こす可能性があります。

SIP アプリケーション属性

ラージ・オブジェクトまたは BLOB を SIP セッション属性として (SIPSession.setAttribute API を介して) ハングしないでください。高可用性 (HA) で結合されている場合、 これによりパフォーマンス全体が低下する場合があります。 この推奨事項は SIPApplicationSession.setAttribute についても該当します。ほとんどの場合、ラージ・オブジェクトはいくつかの単純ストリングまたは構成済みストリングで置き換えることができます。

トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsip_refwrite
ファイル名:rsip_refwrite.html