管理者は、CUCM 管理パネルを使用して、アカウント ロックアウトのオプションを設定できます。

アカウント ロックアウトのオプションを設定する場合、管理者は次のいずれかを実行できます。

1. ユーザのクレデンシャル ページで [管理者によるロック（Locked by Administrator）] チェックボックスをオンにします。

2. ログイン試行回数を設定します。これは、クレデンシャルが無効なためにログインに失敗した回数です。

3. 最大アイドル時間（日数）を設定します。ユーザがその日数の間ログインしなかった場合、アカウントはロックされます。

アカウント ロックアウトの場合、JTAPI は警告メッセージなしで詳細な例外を配信します。アプリケーションでこれらの値を変更することはできません。JTAPI は情報を報告するだけです。

エージェント グリーティング機能を使用すると、エージェント デバイスへのメディア接続が正常に終了した後で録音済みの音声案内が自動的に再生されるよう、JTAPI アプリケーションから Cisco Unified Communications Manager に指示できます。グリーティングを使えば、エージェントはコールのたびに同じフレーズを繰り返す必要がなくなります。エージェント グリーティングは、エージェント側にもカスタマー側にも聞こえます。

エージェント グリーティングは、Built-in-Bridge（BIB）を備えているすべての電話機から開始できます。コールは、BIB から、要求で指定されている DN へ開始されます。アプリケーションにより、このコールに応答し、メディアを再生します。

コールには次の 2 種類があります。

• カスタマーとエージェント間で交わされる基本的なコール。

• 二次的コール（音声自動応答装置（IVR）コールと呼ばれる）。これは、IVR デバイスとエージェントの電話機の BIB の間で作成されます。

アプリケーションは、コールにおいて新しいエージェント グリーティング API を起動し、これによって IVR コールが作成されます。次にアプリケーションはコールに応答し、事前に録音されているメッセージを再生します。

IVR コールではエージェントに対して接続が作成されないため、アプリケーションで把握できるのは二次的コールのみになります。IVR コールには、IVR メッセージを再生するための接続しかありません。

アプリケーションが IVR デバイスを監視しているかどうかに関係なく、エージェント グリーティングのメディアが再生されます。エージェント上のオブザーバは、メディアを開始するためのイベントを受け取ります。メディアが終了すると、アプリケーションは、メディアをストリームしている IVR または CTI ポートの接続を切断する必要があります。2 番めのコールが切断されると、イベントがエージェント上のオブザーバへ送信され、メディアを終了するためのイベントを受け取ります。

この機能は、BIB 搭載の電話機のみで使用できます。ほとんどの Cisco Unified IP Phone は BIB 機能を備えていますが、この機能は、一部の古いモデルまたは低機能モデルの電話機では使用できないことがあります。管理者はデバイスに対して Cisco Unified Communications Manager の管理パネルを使用して BIB を有効に設定する必要があります。

addMediaStream に対する要求が作成されるたびに JTAPI は、タイムアウト エラーにより IVR デバイスがコールに応答するまで、または CTI がタイムアウト エラーで応答するまで要求をブロックします。このことにより、JTAPI は要求が完了するまで待機することをブロックされるため、addMediaStreamRequest を起動した JTAPI スレッドは自身のコールに応答できません。

この機能を使用するアプリケーションは、必ず次のいずれかに該当している必要があります。

• 着信コールに対して自動応答するよう IVR DN が設定されている。

• IVR DN で応答するために、別の JTAPI スレッドまたはアプリケーションが設定されている。

  インターフェイスの変更

CiscoTerminalConnection、CiscoFeatureReason、CiscoJtapiException、CiscoMediaStreamStartedEv、CiscoMediaStreamEndedEvを参照してください。

リリース 10.5(2) の Cisco Unified Communications Manager から、次の暗号化アルゴリズム ID がサポートされるようになりました。

• CiscoMediaEncryptionAlgorithmType

• CiscoMediaEncryptionAlgorithmType.AES_128_COUNTER_80

• CiscoMediaEncryptionAlgorithmType.F8_128_COUNTER_32

• CiscoMediaEncryptionAlgorithmType.F8_128_COUNTER_80

• CiscoMediaEncryptionAlgorithmType.AEAD_128_COUNTER

• CiscoMediaEncryptionAlgorithmType.AEAD_256_COUNTER

CiscoMediaEncryptionAlgorithmType.AEAD_128_COUNTER および CiscoMediaEncryptionAlgorithmType.AEAD_256_COUNTER は 2 つの SIP エンドポイント間のセキュアなコールでのみネゴシエートされます。

CTI ポートは上記のどのアルゴリズムにも登録できますが、セキュアなコールの場合は AES_128_COUNTER_80 でのみネゴシエートします。

一部の機種の IP フォンでは、電話機上で設定可能なロケールに対応するデフォルト スクリプト以外の代替言語スクリプトがサポートされています。たとえば、日本語ロケールには 2 つの表記スクリプトがあります。一部の機種では Katakana スクリプト（デフォルト）しかサポートされていませんが、その他の機種ではデフォルト スクリプトと Kanji スクリプト（代替スクリプト）の両方がサポートされています。アプリケーションは電話機に表示用のテキスト情報を送信できるため、電話機がどの代替スクリプトをサポートしているかを知る必要があります。

新しい getAltScript() メソッドは、監視対象のデバイスの代替スクリプト情報を提供します。現在存在する代替スクリプトは日本語ロケールの Kanji だけです。

JTAPI では、代替スクリプト情報を提供する CiscoTerminal 用の新しいメソッドが提供されています。

JTAPI は CiscoTerminal.isBuiltInBridgeEnabled() という API を公開して、端末上で BIB 機能が有効になっているかどうかをアプリケーションに知らせます。結果として、戻り値は true または false になります。

CiscoMediaTerminal または CiscoRouteTerminal のデバイスでは BIB をサポートしていないため、これらのデバイスで BIB が起動されている場合、API は MethodNotSupportedException をスローします。

Cisco Unified Communications Manager に登録されていない端末の場合は、API は InvalidStateException をスローします。

このバージョンの Cisco Unified JTAPI では、アラビア語とヘブライ語をサポートしています。これらの言語は、インストール時および Cisco Unified JTAPI Preferences のユーザ インターフェイスで選択できます。

Linux ベースの JTAPI クライアント マシンでこの機能をサポートするために、アップデータのインターフェイスに次の変更が加えられました。このインターフェイスでは、アプリケーションは、コンポーネント名、プロバイダーの IP アドレス、ユーザ名、パスワードを提供する必要があります。アプリケーションは、コンポーネントをダウンロードする URL を指定する必要はありません。これは、Cisco Unified Communications Manager Administration の異なるリリースの間で URL が変化した場合に、アップデータ アプリケーションに問題が発生するのを避けるためです。

「Replace()」という新しい API は、コンポーネント インターフェイスの一部です。" "この API を使用すると、古いコンポーネントを新しくダウンロードしたコンポーネントに簡単に置換できます。次のセクションでは、新しいインターフェイスへの変更後のアップデータの動作を定義しています。新しいアップデータは次のように動作します。

• API 署名は、古いものと同じものを使用する。

• 新しいバージョンの jar ファイルとして、アプリケーションの現在のフォルダに newjtapi.jar を作成する。

• 指定されたクラスパスの component.temp というファイルに現在の jtapi.jar をコピーする。

• 現在の jar ファイルを新しい jar ファイルに置換する。この処理が終わると、現在の jar ファイルは component.temp になり、新しい jar ファイルは jtapi.jar になります。アプリケーションでは、URL の取得を、アプリケーションで URL を指定する方法、または CiscoProvider で提供されている新しいインターフェイスを使用して URL を問い合わる方法のいずれかで行う、古いコンポーネント インターフェイスを使用することもできます。URL 情報を取得する必要がある API については、この機能のインターフェイスの概要に記載しています。この処理は、Unix と Windows の両方でサポートされています。

  下位互換性

この機能には下位互換性はありません。

この機能は、CTIPort およびルート ポイントのアドレスの AutoAccept を有効または無効にする機能をアプリケーションに提供します。アドレスの AutoAccept ステータスが変更されると、Cisco Unified JTAPI はイベントを提供してアプリケーションに変更を通知します。

（注）	ルート ポイントでサポートされる回線の最大数は 34 です。

CiscoAddress オブジェクト内に提供された新しい setAutoAcceptStatus() インターフェイスを使用すると、AutoAccept をオンまたはオフに設定できます。同様に、CiscoAddress オブジェクト内に提供された getAutoAcceptStatus() インターフェイスを使用すると、アプリケーションはアドレスの現在の AutoAccept ステータスを照会できます。

アドレスの AutoAccept ステータスが変更されると、アプリケーションは AddressObserver によって CiscoAddrAutoAcceptStatusChangedEv を取得します。このイベントには、AutoAccept ステータスが変更された端末を返す getTerminal() インターフェイスと、AutoAccept がオンまたはオフであるかを示す整数を返す getAutoAcceptStatus() が含まれます。アドレス オブザーバが追加されていない場合、このイベントは提供されません。

次のインターフェイスは、CTIPort および RoutePoint の AutoAccept をサポートしています。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。CTIPort および RoutePoint での AutoAccept のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

Cisco Unified Communications Manager リリースを新しいバージョンにアップグレードした場合、API には Cisco Unified Communications Manager リリースの新しいバージョンとの互換性がある場合とない場合があることに注意してください。アプリケーションが期待どおりに動作できるように、API を互換バージョンにアップグレードしていることを確認してください。API はクライアント サーバにローカルでインストールされるため、複数のマシンをアップグレードする必要があります。少数のクライアント アプリケーションでは、Cisco Unified Communications Manager Administration に接続し、Cisco Unified Communications Manager 互換プラグインをダウンロードしてインストールすることで、より容易にこれを実行できます。

クライアント アプリケーションが複数ある場合、この機能は、アプリケーションが始動時に HTTP 要求を使用して自身の ID を Web サーバに提示し、必要な JTAPI API のバージョンに関する応答を受信するための機能を提供します。

アプリケーションのクラスパスにあるローカルのバージョンと、サーバから取得できるバージョンが比較され、アップグレードが必要かどうかが確認されます。これにより、Cisco Unified Communications Manager に合わせてアプリケーションが jtapi.jar コンポーネントをリフレッシュでき、アプリケーションが自動アップデート可能な jtapi.jar を集中展開することができます。

この機能の実行に必要な API は、updater.jar 形式でパッケージ化されています。jtapi.jar および updater.jar のパッケージには、バージョンの比較に使用できる標準マニフェストが含まれています。

（注）	この機能では、JTAPI Preferences、JTAPITestTools、Updater.jar、javadoc コンポーネントはアップデートされません。アプリケーションにこれらのコンポーネントが必要な場合は、Cisco Unified Communications Manager プラグイン ページから JTAPI をインストールしてください。自動アップデートは、JTAPI Release 2.0 以降をサポートしています。

詳細については、Cisco Unified JTAPI のインストールを参照してください。

API の自動アップデートには、次の新しいインターフェイスまたは変更されたインターフェイスがあります。

Class com.cisco.services.updater.ComponentUpdater

Interface com.cisco.services.updater.Component

また、JTAPI の自動アップデータ機能により、アプリケーションは Cisco Unified Communications Manager から JTAPI.JAR の最新バージョンを直接ダウンロードできます。

1. アップデータにより、アプリケーションの現在のフォルダに newjtapi.jar ファイルが作成されます。これは、Cisco Unified Communications Manager からダウンロードされた新しいバージョンの jar ファイルを表します。

2. アップデータにより、指定されたクラスパスの component.temp というファイルに現在の jtapi.jar がコピーされます。

3. アップデータにより、現在の jtapi.jar が新しい jtapi.jar ファイルに置換されます。

この処理が終わると、現在の jar ファイルは component.temp になり、新しい jar ファイルは jtapi.jar になります。この処理は、Linux と Windows の両方でサポートされています。

自動アップデータの使用例

Command Line : java com.cisco.services.updater.ComponentUpdater <server> <component name> <login> <passwd>Component localComponent,  downloadedComponent;
ComponentUpdater updater  =  new ComponentUpdater();
String localPath  =  updater.getLocalComponentPath(args[1]);
localComponent  =  updater.queryLocalComponentVersion("jtapi.jar",  localPath);
localComponent.copyTo("component.temp");
String provString  =  args[0] + ";login = " + args[2] + ";passwd = " + args[3];

CiscoJtapiPeer peer  =  (CiscoJtapiPeer) (JtapiPeerFactory.getJtapiPeer(null));
CiscoJtapiProperties tempProp  =  ( (CiscoJtapiPeerImpl) (peer)). getJtapiProperties();
tempProp.setLightWeightProvider(true);

Provider provider  =  peer.getProvider(provString);
String url  =  ( (CiscoProvider) (provider)).getJTAPIURL(); provider.shutdown();
Component serverComponent  =  updater.queryServerComponentVersion("jtapi.jar",  url);

downloadedComponent  =  serverComponent.fetchFromServer();
int retVal  =  downloadedComponent.replaces(localComponent);

「replaces」API は、既存の JTAPI バージョンを新しいバージョンに置き換えます。" "

（注）	アップデータは JTAPI.JAR ファイルのみを更新し、JTAPI プラグインにバンドルされているその他のサンプル アプリケーションや Cisco JTAPI ドキュメントを更新しません。これらの他のコンポーネントを取得するには、アプリケーションで Cisco Unified Communications Manager からプラグインをダウンロードしてインストールする必要があります。

割り込み機能は、別端末のアドレスで確立されたコールに共用アドレスが割り込み処理できる機能です。この機能は、TerminalConnection アドレスが Passive 状態で、CallControlTerminalConnection が Bridged 状態である場合に有効です。Cisco Unified JTAPI のこのバージョンでは、アプリケーション制御による端末（IP フォン）から手動で機能を有効にすることだけがサポートされます。このリリースでは、API から機能を有効にすることはできません。

プライバシー機能は、他の共有アドレスからコールへの割り込み処理を有効または無効にできる機能です。プライバシーを有効にすると、他の共有アドレスからコールに割り込めません。また、無効にすると、割り込みができます。プライバシーは、端末のプロパティを示します。IP フォンには [プライバシー（Privacy）] ソフトキーがあり、このソフトキーを押すと、プライバシーが有効または無効になります。" "端末のアクティブ コールの場合、プライバシーを動的に有効または無効にすることができます。コールのプライバシーがオンになっているときは、共有アドレス上にあるコール アピアランスの TerminalConnection" "は「InUse」状態です。CallProgress 中にプライバシー ステータスが変化した場合、CiscoTermConnPrivacyChangedEvent がアプリケーションに配信されます。

Cisco Unified Communications Manager には、「割り込み」と呼ばれる組み込みの会議ブリッジを使用するものと、「C 割り込み」と呼ばれる共有会議ブリッジ リソースを使用するものの 2 種類があります。" "" "アプリケーションにとっては、割り込みと C 割り込みの間でのインターフェイスの変更はありません。ただし、一部動作の違いがあり、これらはメッセージ シーケンスの図にあるメッセージ フローの図に記載されています。

割り込み、C 割り込みおよびプライバシーには次のインターフェイスがあります。

Interface CiscoTerminalConnection

booleangetPrivacyStatus()

このインターフェイスは、端末上にあるコールのプライバシー ステータスを返します。

Interface CiscoTermConnPrivacyChangedEv

javax.telephony.TerminalConnectiongetTerminalConnection()

CiscoCall.CAUSE_BARGE という新しい原因コードが、割り込みの CiscoCall に追加されています。

割り込みの結果、SharedLine TerminalConnection または CallCtiTerminalConnection が Active 状態または Talking 状態になると、JTAPI は CiscoCall.CAUSE_BARGE として CallCtiCause を提供します。この原因コードは、割り込み処理中に作成される一時コールをドロップする際に使用される CallCtiEvent でも提供されます。

C 割り込みでは、この原因コードは提供されません。

これらのインターフェイスの詳細については、Cisco Unified JTAPI 拡張を参照してください。割り込み、C 割り込み、およびプライバシーのメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

コール制御ディスカバリ（CCD）機能により、コール エージェント間通信に対するプロビジョニングが容易になります。この機能は Service Advertisement Framework（SAF）ネットワーク サービスを使用して、自身をコール制御エンティティとして通知し、ネットワーク上の他のコール制御エンティティ（Cisco Unified Communications Managers または CME）を検出して、これらのルーティングの動作について動的に適応できるようにします。

異なるクラスタにある 2 つのデバイス間でコールが実行され、未割り当て、未指定番号、およびユーザがビジー以外の原因コードでコールが拒否されると、CCD 機能により、PSTN ネットワークへのコールがフェールオーバーされます。つまり、コールは、IP ネットワークではなく PSTN ネットワークを介してルーティングされ、同じ宛先に到達します。

JTAPI は SAF CCD 機能をサポートしています。ただし、PSTN トランクへの通常の SAF コールがフェールオーバーしてもアプリケーションには通知されません。

JTAPI では、宛先へのリダイレクトまたは転送に対して作成された新しい Connection について、新しい理由 CiscoFeatureReason.REASON_SAF_CCD_PSTN_FAILOVER が追加されています。これは、SAF トランク経由でクラスタ全体でリダイレクトまたは転送があり、PSTN トランクへのコールがフェールオーバーする場合に発生します。

Cisco Unified JTAPI では、JTAPI 仕様に適合したコール転送機能の設定がサポートされています。Cisco Unified JTAPI 実装では、すべての転送特性はサポートされず、アドレスの FORWARD_ALL 属性だけがサポートされます。CallControlAddress オブジェクトの setForwarding、getForwarding および cancelForwarding のメソッドをアプリケーションによって呼び出すことができますが、CallControlForwarding 命令は FORWARD_ALL のものだけが可能です。

この機能では、コール転送のすべての機能をオーバーライドするメカニズムが提供されます。ユーザ（CFA の開始者）が CFA を別のユーザ（CFA ターゲット）に設定した場合、CFA ターゲットが CFA の開始者をコールするのであれば、CFA は無視される必要があります。これにより、CFA ターゲットは重要なコールを CFA の開始者に着信させることができます。

この CallManager 機能の動作は、サービス パラメータ（CFADestinationOverride）を使用して設定できます。

例：Alice は DN 1000 の電話機を所持しています。* Bob は DN 2000 の電話機を所持しています。* Daniel は DN 4000 の電話機を所持しています。* Alice は CFA を 2000 に設定しています。

CFA の動作を次に示します。* Bob が Alice をコールするとします。コールは Alice に着信し、CFA の設定に従った Bob に戻るという動作はしません。* Daniel が Alice をコールするとします。このコールは CFA 設定に従って Bob に転送されます。* Bob はコールに応答し、Alice にそのコールを転送します。Alice が自分への電話を Bob に転送したため、Bob はこの操作を実行できます。この機能では、JTAPI レイヤに対するインターフェイスの変更はありません。ただし、CiscoAddress.setForward() API の起動時には、JTAPI アプリケーションでは異なる動作が確認される場合があります。例のように、CFA ターゲットが CFA の開始者をコールするシナリオでは、機能が有効に設定されている場合、コールは転送されません。

Cisco Unified JTAPI は、ユーザのコール パークとの対話をサポートし、アプリケーションに適切なイベントを報告します。コールが IP フォンからパークされると、パーク アドレスに属する Connection は、Disconnected 状態に移行し、関連する TerminalConnection は、Dropped 状態に移行します。パーク番号に対してキュー状態の新規 Connection が作成されます。

コールのパークされたアドレスだけをアプリケーションがモニタしている場合、すべての既存の Connection は解除され、TerminalConnections が破棄されてコールは Invalid 状態に移行します。

コール ピックアップを使用すると、デバイスでは、コール ピックアップ グループ内のアラートやイベントを受信することができ、各種のコール ピックアップをサポートする API を起動することによって、これらのアラートに対する動作を実行できます。

これらの API を使用すると、アプリケーションでは、既存のコール ピックアップ グループについて情報を収集し、特定のピックアップ グループに対するピックアップ アラートの受信を登録および登録解除することができます。

JTAPI では、ピックアップ、グループ ピックアップ、他グループ ピックアップ、ダイレクト ピックアップをアプリケーションから起動できます。Cisco Unified Communications Manager のリリース 8.0(1) より前のリリースでは、他グループ ピックアップを除くこれらのすべての機能が監視イベントとしてサポートされていましたが、起動はサポートされていませんでした。

（注）	コール ピックアップは、CTI ルート ポイントではサポートされません。

機能によって、または手動でコールを選択した場合、Cisco Unified JTAPI により CiscoTermConnSelectChangedEv イベントが送信されます。アプリケーションはこのイベントを受信すると、TerminalConnection.getSelectStatus() を使用して正確なコールの選択状態を取得できます。TerminalConnection.getSelectStatus() を呼び出すと、次の 3 つの状態のいずれかが返されます。

• CiscoTerminalConnection. CISCO_SELECTEDNONE：この選択状態は、コールが選択されていないことを示します。

• CiscoTerminalConnection. CISCO_SELECTEDLOCAL：この選択状態は、コールが TerminalConnection で選択されていることを示します。

• CiscoTerminalConnection. CISCO_SELECTEDREMOTE：コールがその共用回線で選択されている場合、Passive TerminalConnection がこの選択状態を受け取ります。

この機能を使用すると、[不在（CallFwdAll）] キーが有効にされたときに、コールが通常コールか一時コールかをアプリケーションで認識できます。

JTAPI では、API getCFwdAllKeyPressIndicator() 経由でこの情報が公開され、これは CiscoCall インターフェイスによって公開されます。この API により、[不在（CallFwdAll）] ソフトキーを押すことによってコールが作成されたかどうかを、アプリケーションで認識できるようになります。新たに追加された getCFwdAllKeyPressIndicator()" により、次の新しい定数が返されます。

• オンフック状態ではない電話機でこのキーが押されて CallFwdAll が設定された場合、この API は、CiscoCall.CFWD_ALL_SET を返します。

• オンフック状態ではない電話でこのキーが押されて CallFwdAll がクリアされた場合、この API は、CiscoCall.CFWD_ALL_CLEAR を返します。

• まずコールが実行され、その後に電話機がオフフック状態のときに [不在（CallFwdAll）] キーが押された場合、この API は、CiscoCall.CFWD_ALL_NONE を返します。

  インターフェイスの変更

を参照してください。 CiscoCall

直接転送または参加などの操作を行うために、電話のコールを選択または選択解除できます。SharedLine ユーザがコールを選択すると、回線を共用している他の TerminalConnection は、Passive 状態になり、CallCtlTermiCallConnection は InUse 状態になります。コールの選択が解除されると、CallCtlTerminalConnection が Bridged 状態になります。Passive または InUse の TerminalConnection については、アプリケーションから API を呼び出せません。（転送/会議などの）機能動作中の CallProcessing でも、Select/UnSelect 操作を実行できます。アプリケーションが RemoteInUse 端末をモニタしている場合、アプリケーションは次のイベントも受け取ります。

たとえば、A と A' が SharedLine の場合、A がコールを選択すると、A' の CallCtlTerminalConnection は Passive 状態または InUse 状態になります。A がコールの「UnSelect」を実行した場合、A' の" "CallCtlTerminalConneciton は Passive 状態または Bridged 状態になります。

CallSelect または UnSelect に関するメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

現在、Cisco Unified JTAPI の証明書のダウンロード API にはセキュリティ上の問題があり、この問題を解決するために、新しい証明書のダウンロード API を提供しています。新しい API では、アプリケーションが証明書のパス フレーズを指定する必要があります。証明書のパス フレーズは、クライアント/サーバ証明書が格納された Java キー ストアの暗号化に使用されます。

古い証明書のダウンロード API の使用は推奨しませんが、この API は、アプリケーションの下位互換性の問題を避けるために、まだ残されています。アプリケーションを新しい API に移行することを強く推奨します。

また、Cisco Unified JTAPI では、新しい API の deleteCertificate() と deleteSecurityPropertyForInstance() も提供されます。これらをアプリケーションで使用すると、すでにインストールされている証明書を削除できます。証明書の Java キー ストアのパス フレーズを変更する場合は、この API を使用して古い証明書を削除し、新しい証明書をアップロードする必要があります。

JTAPIPreferences UI の [セキュリティ（Security）] タブの拡張により、[証明書を削除する（DeleteCertificate）] と [証明書を更新する（Update Certificate）] という 2 つの新しいボタンが追加されました。[証明書を削除する（DeleteCertificate）] ボタンを使用すると、ユーザは目的のユーザ名またはインスタンス ID の証明書を削除できます。[証明書を更新する（Update Certificate）] ボタンを使用すると、ユーザは CAPF サーバから証明書をアップロードできます。証明書のアップロードが成功すると、証明書の更新ボックスの内容が更新されて更新済みであることが示され、認証文字列と証明書パス フレーズがクリアされます。証明書の更新操作が失敗した場合は、証明書が前に更新されていない限り、証明書ボックスに [未更新（Not Updated）] のステータスが示されます。ユーザとアプリケーションは、証明書の更新を行うたびに証明書パス フレーズを提供する必要があり、Cisco Unified JTAPI ではどのような環境下でもセキュリティ上の理由で証明書パス フレーズは保存されません。パス フレーズのセキュリティを確保し、必要な場合には API を通じてパス フレーズを提供することはアプリケーション側の責任です。

現在、TAPI Service Provider（TSP）ではデバイス タイプ名がデバイス タイプに応じてハードコーディングされています。新しいデバイス タイプが追加された場合は、新しいデバイス タイプ名をサポート対象デバイスのリストに手動で追加する必要があります。Computer Telephony Integration（CTI）はデバイス タイプ名を CTI 自身のキャッシュに取得して格納することがないため、TSP ではこの情報を CTI から取得できません。TSP では、手動による操作がないまま新しいデバイス タイプが追加されたときに、デバイス タイプ名を更新する必要があります。

CTI から送られ、deviceInfo 構造体に格納されているデバイス タイプ名の受信が処理されるように Quick Buffer Encoding（QBE）インターフェイスの変更が JTAPI に加えられました。deviceInfo は JTAPI ではまったく使用されておらず、アプリケーションにも公開されません。QBE インターフェイスだけが次のように変更されました。

public DeviceRegisteredEvent ( String ride, int deviceType, boolean allowsRegistration, int deviceID, boolean loginAllowed, UnicodeString userID, boolean controlled, int reasonInt, int registrationType, int unicodeEnabled, int locale, // added for deviceTypeName change String devTypeName) { public DeviceUnregisteredEvent ( String deviceName, int deviceType, boolean allowsRegistration, int deviceID, UnicodeString userID, boolean controllableBool, int reasonInt , int locale, //added for devtypename support String devTypeName) {

JTAPI では、端末オブジェクトは、コールに対する論理エンドポイントを表し、データ（デジタルでエンコードされた音声サンプルなど）の送受信が可能であると想定されます。このため、Cisco Unified IP Phone は、JTAPI の端末として表現されます。ただし、ゲートウェイは、メディア終端を実行しますが、端末としては表現されません。CiscoMediaTerminal が、アプリケーションがメディア終端を担当する特殊なエンドポイントを表します。

CiscoMediaTerminal の使用に関連する手順は次の 4 つです。

• プロビジョニング

• 登録

• オブザーバの追加

• コールの受け入れ

エンドポイントは、Cisco Unified Communications ソリューションのプラットフォーム上で、IP フォンやゲートウェイなどのメディアを終端するエンティティを表します。1 つのエンドポイントから別のエンドポイントへのコールによって、2 つのエンドポイント間にメディアのフローが生じます。Cisco Unified Communications ソリューションのプラットフォーム内にあるすべてのエンドポイントにおいて、Real-Time Protocol（RTP）を使用して音声データが送信されます。たとえば、Cisco Unified Communications ソリューションの電話機とゲートウェイには、RTP スタックが組み込まれています。また、アプリケーションが Cisco Unified Communications ソリューションのシステム内でエンドポイントとして機能し、メディアを終端することも可能です。すべての Cisco Unified Communications ソリューションのエンドポイントにおいて RTP が使用されるため、アプリケーションにも RTP パケットを送信および受信する機能が必要です。

Cisco Unified Communications Manager サーバに障害が発生すると、関連付けられたデバイスはグループ内の次の Cisco Unified Communications Manager サーバにリホームします。このプロセスは、デバイスごとのデバイス プール情報の設定にある Cisco Unified Communications Manager の優先順位付きリストで定義されます。

Cisco Unified Communications Manager サーバの障害時でも、クラスタ内にあるデバイスの部分的な機能停止が生じるだけです。それらのデバイスは、Cisco Unified Communications Manager フェールオーバーとセカンダリ Cisco Unified Communications Manager への登録の成功の後、引き続き使用可能になります。

（注）	Cisco Unified IP Phone 7960 などのデバイスでは、デバイス上にアクティブ コールがないときにだけ、セカンダリの Cisco Unified Communications Manager サーバに対するフェールオーバーが行われます。コール中の Cisco Unified Communications Manager サーバの障害では、そのデバイスの監視が停止するだけです。メディア パスはそのまま存在しますが、コール制御は機能しません。

Cisco Unified JTAPI では、CiscoAddrOutOfServiceEv イベントと CiscoTermOutOfServiceEv イベントを使用して、この部分的な機能停止がアプリケーションに伝えられます。Cisco Unified Communications Manager がフェールオーバーした場合、デバイスが JTAPI アプリケーションで使用可能になる前に、そのデバイスがセカンダリ Cisco Unified Communications Manager への登録に成功する必要があります。Cisco Unified JTAPI からは、CiscoAddrInServiceEv イベントと CiscoTermInServiceEv イベントが送信されます。

この間、プロバイダーはイン サービス状態にあります。他の Cisco Unified Communications Manager サーバ上のデバイスは、コール制御に使用可能なままです。イベントは、個々のアドレスまたは端末のオブザーバ オブジェクトがコールバックされると送信されます。CiscoAddrOutOfServiceEv イベントと CiscoAddrInServiceEv イベントは、AddressObserver を実装しているオブジェクトに送信され、addressChangedEvent() コールバック オブジェクト メソッドを使用してアドレスに通知されます。CiscoTermOutOfServiceEv イベントと CiscoTermInServiceEv イベントは、TerminalObserver インターフェイスを実装しているオブジェクトに送信され、terminalChangedEvent( ) コールバック メソッドを使用して端末に通知されます。

デバイスに現在コールがある場合は、CallObservationEnded メッセージが CallObserver callChangedEvent() のコールバック時に送信され、次に、CiscoAddrOutOfServiceEv メッセージと CiscoTermOutOfServiceEv メッセージが送信されます。

（注）	アプリケーションでは、アドレスまたは端末のコール制御関数を呼び出す前に、CiscoAddrOutOfServiceEv、CiscoTermOutOfServiceEv、CiscoAddrInServiceEv、および CiscoTermInServiceEv のイベントのモニタおよび応答を実行する必要があります。このアクションをサポートしない場合、アプリケーション側でシステムの正確な状態を把握できないため、予想外のエラーが生じる可能性があります。

Cisco Unified IP 7931G フォンは、次の 2 つのモードに設定できます。

• NoRollOver

• RollOver（同じ DN 間または異なる DN 間で）

Cisco Unified IP 7931G フォンが NoRollOver モードに設定されると、Skinny Call Control Protocol（SCCP）を実行する通常の電話機と同様に機能します。このモードでは、異なるアドレス間で転送や会議を実行できません。JTAPI は、7931G フォンが NoRollOver モードに設定されている場合、制御およびモニタリングをサポートします。

RollOver モードでは、Cisco Unified IP 7931G フォンは、異なるアドレス間での転送や会議をサポートします。このモードでは、JTAPI は、Cisco Unified IP 7931G フォンの制御およびモニタリングができません。アプリケーションでは、このような端末やアドレスは制限されていると認識されます。Cisco Unified IP 7931G フォンがアプリケーション ユーザのコントロール リストに含まれており、設定が NoRollOver から RollOver モードに変更されると、JTAPI は、原因 CiscoRestrictedEv.CAUSE_UNSUPPORTED_DEVICE_CONFIGURATION で、CiscoAddrRestrictedEv イベントを Cisco Unified IP 7931G フォンの各アドレスに送信し、CiscoTermRestrictedEv を各端末に送信します。

ただし、電話の設定が RollOver から NoRollOver モードに変更されると、JTAPI は、CiscoAddrActivatedEv イベントを Cisco Unified IP 7931G フォンの各アドレスに送信し、CiscoTermActivatedEv を各端末に送信します。

RollOver モードに設定されている Cisco Unified IP 7931G フォンが JTAPI によって制御されたアドレスに転送または会議を発信すると、JTAPI のアプリケーションは最終コールとコンサルト コールで共通のコントローラを認識しません。これにより、JTAPI アプリケーションの動作が異なってきます。JTAPI アプリケーションがイベントの情報を処理している方法によっては、この転送または会議の場合に JTAPI イベントを処理する方法を変更する必要があります。

異なるアドレス間での転送および会議を無効にするには、Cisco Unified Communications Manager Administration の電話の設定ウィンドウで、Cisco Unified IP 7931G フォンを NoRollOver（ロールオーバーなし）モードに設定します。

CiscoRestrictedEv インターフェイスには、2 つの新しい原因コードがあります。Cisco Unified IP 7931G フォンが RollOverMode に設定されているために端末またはアドレスが制限されている場合、JTAPI は原因 CiscoRestrictedEv.UNSUPPORTED_DEVICE_CONFIGURATION で CiscoAddrRestrictedEv を送信します。また、このリリースではデフォルトの原因コード CAUSE_UNKNOWN も導入されており、これはアプリケーションが処理可能です。

Cisco Unified JTAPI では、JTAPI のインストールとユーザ プリファレンスの UI に複数の言語がサポートされています。JTAPI が起動すると、インストール用の言語を選択するオプションが表示されます。言語を選択すると、その後のインストールの指示は選択した言語で表示されます。最初のオプションは常に英語です。英語以外の言語で欠落している語句がある場合、指示はデフォルトの英語になります。詳細については、「Cisco Unified JTAPI のインストール」を参照してください。

Cisco Unified JTAPI は、Cisco Voice Gateway（VG）248 および Analog Telephone Adaptor（ATA）186 アナログ電話ゲートウェイに接続されているアナログ電話の制御をサポートします。Cisco VG248 および ATA 186 アナログ電話ゲートウェイをユーザ コントロール リストに追加すると、これらのデバイスをアプリケーションで制御できます。

アプリケーションには、他の IP フォンと同様の方法でデバイスに関するイベントが送信されます。また、アプリケーションでは、コールを発信できるほか、API による応答要求を除くその他の機能を呼び出すこともできます。発信が実行されるのは、デバイスが物理的にオフフック状態にある場合だけです。

デバイスに対する API からのコールにアプリケーションが応答できません。アプリケーションが VG248 および ATA 186 端末に対する TerminalConnection で () を応答しようとすると、CiscoJtapiException.COMMAND_NOT_IMPLEMENTED_ON_DEVICE というエラーを示す PlatformException が送出されます。コールに応答するには、受話器を手で持ち上げる必要があります。それによって、API による転送、会議、ブラインド転送、パークなど、その他のコール制御機能を呼び出せるようになります。

Cisco Unified JTAPI では、アプリケーションに CTI 生成のエラー コードが通知されます。これらのコードは、CTIManager に例外またはエラーがある場合に返されます。CTI で返されたエラー コードは、それぞれアプリケーションに伝搬されます。アプリケーションでは、例外オブジェクトの getErrorCode() メソッドの呼び出しによるエラー コードの抽出、getErrorName() メソッドの呼び出しによる CTI エラー コードの取得、およびメソッド getErrorDescription() の呼び出しによるエラー記述の取得ができます。

CiscoJtapiExceptions インターフェイスでは、JTAPI でのエラー コードを定義します。

PlatformException がスローされた場合、クエリーでエラー コードを取得できます。それを、次のエラー メッセージと比較できます。

CiscoProvAuthenticationInfoEv コードは、アプリケーションにパスワードの有効期限が間もなく切れるか、すでに切れていることを通知するために返されます。このイベントを受け取るには、Provider オブジェクトにプロバイダー オブザーバが必要です。

アプリケーションが接続を起動し、パスワードの有効期限が切れたために接続に失敗すると、アプリケーションは新しく定義されたエラー コードとともに PlatformException を受け取ります。詳細については、CiscoJtapiExceptionsを参照してください。

フェールオーバーの場合、アプリケーションは明示的に接続を要求せず、PlatformException を受け取りません。プロバイダーにはオブザーバが存在するので、プロバイダーは getDaysUntilPasswordExpiry() = CiscoProvAuthenticationInfoEv.PASSWORD_EXPIRED とともに CiscoProvAuthenticationInfoEv をオブザーバに配信します。

次のインターフェイスは、アプリケーションがイベントから CiscoRTPHandle を取得できるように拡張されました。

• CiscoRTPInputStartedEv

• CiscoRTPInputStoppedEv

• CiscoRTPOutputStartedEv

• CiscoRTPOutputStoppedEv

CiscoRTPHandle は、Cisco Unified Communications Manager のコールの CallID を表し、端末上でコールがアクティブな間は変化しません。コールと関連付けられた GCID が変更されても、特定の端末/アドレス上では CiscoRTPHandle は一定に保たれます。

JTAPI 2.0 リリースよりも前では、Cisco Unified JTAPI アプリケーションは端末イベントを直接制御できませんでした。端末オブザーバに適切なフィルタを設定することで、アプリケーションがボタン押下イベントを受信できるようになりました。アプリケーションで RTP イベントを取得するために、コール オブザーバを追加する必要はなくなりました。

CiscoTermEvFilter を使用して setButtonPressedEv が有効にされている場合、電話機で数字ボタンが押されたときに、アプリケーションは CiscoTermButtonPressedEv を受信します。

CiscoTerminal Filter と ButtonPressedEvent には、次の新しいインターフェイスまたは変更されたインターフェイスがあります。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。CiscoTerminal フィルタと ButtonPressedEvent のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

CiscoMediaTerminal または CiscoRouteTerminal の登録が非同期で失敗すると、アプリケーションにこのイベントが提供されます。登録が失敗すると、通常、アプリケーションは CiscoRegistrationFailedException を取得します。ただし、登録要求が正常に行われても、CTI によって登録が拒否される可能性もあります。このイベントは、登録要求が正常に行われても、登録が拒否された場合に提供されます。このイベントを受信するには、アプリケーションに TerminalObserver が必要です。このイベントを受信したときに提供されるエラー コードによっては、アプリケーションが新しいパラメータを使用して再登録する必要があります。

次に、返されるエラーと、解決するためにアプリケーションが行う必要のある処置の一覧を示します。

シスコによって導入された無線デバイス（たとえば Cisco Cius など）には、単一の CiscoUCM への登録を保持したまま WiFi ネットワーク間を移動する機能があります。ただし、ネットワークの変更により、デバイスの IP アドレスが変更される場合があります。Cius などのワイヤレス デバイスのこのような IP アドレスの変更を示すために、Cisco JTAPI では 9.0.1 リリースのアプリケーションに対して新しいインターフェイスが公開されます。

新しいプロバイダー イベント（CiscoProvTerminalIPAddressChangedEv）は、端末の IP アドレスが変更されたことを示します。アプリケーションで Cius デバイスをサポートする予定がない場合は、この新しいイベントを無視することもできます。

このイベントを受け取った場合、アプリケーションは新しいイベントまたは CiscoTerminal で公開されているメソッドを使用して、変更された端末の IP アドレスを照会できます。また、このインターフェイスでは、照会できる端末の IPv4/IPv6 アドレスに基づいて、端末の IP アドレッシング モードを公開します。

public synchronized void providerChangedEvent( ProvEv[] eventList ) { try { for ( int i = 0; i < eventList.length; i++ ) { case (eventList[i].getID()) ){ switch: CiscoProvTerminalIPAddressChangedEv.ID: Terminal term = eventList[i] .getTerminal(); int ipAddrMode = eventList[i].getIPAddressingMode(); InetAddr ipV4Addr = null; InetAddr ipV6Addr = null; if(ipAddrMode = CiscoTerminal.IP_ADDRESSING_MODE_IPv4) { ipV4Addr = eventList[i].getIPv4Address(); } else if(ipAddrMode = CiscoTerminal.IP_ADDRESSING_MODE_IPv6) { ipV6Addr = eventList[i].getIPV6Address(); } System.out.println(" TerminalName = " + term.getName() + " ipAddressing Mode = " + ipAddrMode + " IPv4 Address = " + ipV4Addr + " IPv6 Address = " + ipV6Address); } } catch (exception e) { … } }

Cisco Unified JTAPI アプリケーションでは、アクティブ コールを破棄せずにファントム コールをクリアできます。CiscoAddress には clearCallConnections メッセージがあり、これにより、Cisco Unified Communications Manager（以前の Cisco Unified Call Manager）上にアクティブ コールがないときにアプリケーションによってコールをクリアできます。

クリック ツー会議機能では、Instant Messenger（IM）などのアプリケーションで会議に通話者を追加できる、SIP トランクのインターフェイスが提供されます。ユーザは、このようなアプリケーションを使用して、他のユーザを会議に追加したり、ユーザを削除することができます。クリック ツー会議機能を使用してユーザを会議に追加すると、ターゲット アドレスにコールが提供されます。ターゲット アドレスの 1 つのアドレスだけが、この最初のコール上に作成されます。これにより、このコールは会議に追加され、ターゲット アドレスに新しい callID が作成されます。さらに、このコールの他のアドレスへの接続は新しいコール上に作成されます。

ここでは、クリック ツー会議機能を使用してアドレスが会議に追加されたときに、その対話を処理するための Cisco Unified JTAPI のインターフェイスの変更について説明します。クリック ツー会議機能を使用すると、コンサルト コールは行われず、Cisco Unified JTAPI アプリケーションでは CiscoConferenceStartEv または CiscoConferenceEndEv が受信されません。

この機能を無効にするには、CallManager のサービス パラメータ「ENABLE CLICK TO CONFERENCE」をオフにします。" "

CTIManager は、クラスタ内にあるすべての Cisco Unified Communications Manager の仮想表現を提供します。Cisco Unified JTAPI アプリケーションは、特定の Cisco Unified Communications Manager ではなく、CTIManager と通信します。CTIManager はクラスタ内の Cisco Unified Communications Manager 間の接続も維持します。これにより、プロバイダーは CTIManager を使用してクラスタ内のすべてのデバイスを表現できます。図 1 は「図 1」を図示し、図 2 は 「図 2」を図示しています。

クラスタ管理とデバイス プール設定に関する詳細については、Cisco Unified Communications Manager ヘルプの情報を参照してください。

（注）	以前のリリースの Cisco Unified Communications Manager では、Cisco Unified JTAPI 上で実行されるアプリケーションは、単一の Cisco Unified Communications Manager に登録されたデバイスのみ制御や監視が可能でした。Cisco Unified Communications Manager サーバがダウンした場合、Cisco Unified Communications Manager サーバと JTAPI との接続は終了し、プロバイダーはシャットダウンします。

このモードは、Linux アカウントなど、GUI をサポートしていないシステムに JTAPI をインストールする場合に便利です。すべてのインストール手順が文字入力ベースのメニューによって示され、ユーザはインストール時の条件に基づいて一連の入力を行うように求められます。このモードでは GUI ベースのインストーラで提供されているその他のオプションもすべて使用できます。

Component Updater インターフェイスは、アプリケーションで更新ログの場所を指定できるように拡張されました。現在、更新ログは、アプリケーションと同じディレクトリに作成されます。この拡張により、アプリケーションはトレースの場所を指定できます。

JTAPI では、2 つのコールで会議を行うときには、一方のコールのすべての通話者をもう一方のコールに移動することが規定されています。所属していた通話者が移動され、それ以降、無効になるコールは、「マージ」コールまたは「コンサルト」コールと呼びます。マージされた通話者の移動先のコールを、これ以降「最終」コールと呼びます。通話者がマージ コールから最終コールに移動するとき、アプリケーションでは、すべての通話者がマージ コールから破棄されたことを示すイベント、およびこれらの通話者が最終コールに再現されたことを示すイベントが受信されます。

新たに作成された Connection オブジェクトと古い Connection オブジェクトの相関を取るには、CiscoConection.getConnectionID() メソッドを使用して、すべての新旧の Connection に対する CiscoConnectionID オブジェクトを取得します。Connection が一致する場合は、CiscoConnectionID.equals() メソッドを使用して比較したときに CiscoConnectionID オブジェクトが一致します。

会議サポートは、次のメソッドに存在します。

• javax.telephony.callcontrol.CallControlCall.conference(Call)

• javax.telephony.callcontrol.CallControlCall.getConferenceController()

• javax.telephony.callcontrol.CallControlCall.getConferenceEnable()

• javax.telephony.callcontrol.CallControlCall.setConferenceController(TerminalConnection)

• javax.telephony.callcontrol.CallControlCall.setConferenceEnable(boolean)

（注）	Cisco Unified Communications Manager Release 8.6 の時点では、JTAPI/TSP を利用した Cisco TelePresence MCU 会議ブリッジがサポートされます。JTAPI/TSP から見ると、この会議ブリッジはサポートされている他の会議ブリッジと同じように動作します。

会議機能は、1 つのコールで 3 者以上の会議を行う機能を提供します。新しい CTI イベントをサポートするために、CTI 層のイベントが変更され、Cisco Unified JTAPI が拡張されています。

参加機能は、複数のコールを 1 つの電話会議に参加させる機能を提供します。この機能は複数のコールをサポートするようになりました。アプリケーションは、会議に参加するコールの配列を渡す必要があります。

会議と、1 つの電話会議への複数コールの参加処理用に、次の新しいインターフェイスまたは変更されたインターフェイスがあります。

• 次のインターフェイスを使用すると、1 つの電話会議に複数のコールの参加を行うことができます。Call.Conference(Call[] otherCalls)

  （注）	事前条件として、他のすべての otherCalls がコントローラをコールのレッグとして持つ必要があります。

• 次の新しいまたは変更されたインターフェイスが、CiscoConferenceStartEv にあります。

  • TerminalConnection getHeldConferenceController()：このインターフェイスは 2 つのコールの任意会議だけに有効で、保留されたコールのうち 1 つだけを返します。

  • TerminalConnection[] getHeldConferenceControllers()：このインターフェイスは、複数のコールを参加させる際にすべての保留中のコールを取得します。

  • TerminalConnection getTalkingConferenceController()：このインターフェイスは、会話中の会議コントローラを返します。ただし、会議に参加しているすべてのコールが保留され、会話中の会議コントローラがない場合、このインターフェイスは null を返します。

  • Call getConferencedCall()：このインターフェイスは、会議に参加する多数のコールのうち 1 つだけを返します。3 つ以上のコールがある場合の参加会議に関しては、無意味である可能性があります。

• CiscoConferenceEnded イベントの新しいインターフェイス、isSuccess()：

  このインターフェイスは、会議が正常に実行されたか失敗したかに応じて、True または False を返します。アプリケーションは、このインターフェイスを使用して、会議が正常に実行されたかどうかを確認できます。次のイベントは会議の失敗として定義されます。

  • アプリケーションが Call.conference(otherCalls[]) 要求を発行し、1 つ以上のコールが会議に参加できなかった場合、この会議は失敗と見なされます。アプリケーションは、getFailedCalls() インターフェイスを使用して、失敗したコールを見つけることができます。

  • 会議ブリッジがなく、会議がまったく開催できなかった場合、アプリケーションは、getFailedCalls() を使用して、会議に参加できなかったコールのリストを取得できます。

  • 会議が開催できる前に会議に参加していた側がドロップした。

• CiscoConferenceEnded イベントのインターフェイス（Call[] getFailedCalls()）は、会議が失敗した際に、会議への参加に失敗したすべてのコールを取得します。

会議の新しい動作または変更された動作を次に示します。

• 任意会議が発生した時点でアプリケーションが確認できるような保留中または保留解除のメッセージはありません。

• 任意会議で、いずれかのコールが通話中状態にある必要があるという事前条件はなくなりました。ただし、他のすべての otherCalls がコントローラをコールのレッグとして持つ必要があります。

• アプリケーションは、2 つ以上の保留中のコールを電話会議に追加できます。finalCall では、コントローラが自動的に Talking 状態に戻ります。

• Call.Conference(otherCalls) 要求にはアクティブ コールを必ず含めてください。会議要求にアクティブ コールが含まれていない場合、要求が失敗します。

• コントローラにアクティブ コールがない場合、Call.Conference(otherCalls) 要求は正常に実行されます。ただし、アクティブ コールが 1 つある場合は、要求に含める必要があります。

• アプリケーションに引数としてアクティブな TerminalConnection が渡されていない場合、Call.consult() は PreConditionException/InvalidArgumentException をスローします。

• コントローラにアクティブな TerminalConnection がない場合、Call.Conference()/Call.Conference(Call[]) は PreconditionException/InvalidArgumentException をスローします。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。会議と参加のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

会議のチェーニング機能を使用すると、アプリケーションが 2 つの別々の電話会議を繋げることができます。JTAPI アプリケーションでは、チェーニングされた電話会議は 2 つの別々のコールとして認識されます。電話会議がチェーニングされると、JTAPI によって会議チェーン用に新しい Connection が作成され、CallCtlCallObserver に CiscoConferenceChainAddedEv イベントが提供されます。会議のチェーンがコールから削除されると、JTAPI によって会議チェーンの Connection が解除され、CallCtlCallObserver に CiscoConferenceChainRemovedEv イベントが提供されます。アプリケーションは、CiscoConferenceChainAdded/RemovedEv から、すべての会議チェーン Connection へのリンクを提供する CiscoConferenceChain を取得できます。

次の図は、電話会議 GC1 に参加している通話者 A、B、C と、電話会議 GC2 に参加している通話者 C、D、E を示しています。

会議チェーンが作成された後、コールは次の図のようになります。

アプリケーションは、チェーニングされた会議のすべての参加者を CiscoChainedConference オブジェクトから取得できます。このオブジェクトは、チェーニングされているすべての電話会議の会議チェーン Connection を返します。Connection のリストを参照することにより、すべてのチェーニングされた電話会議のリストを取得できます。ただし、各会議から最低 1 人の参加者がアプリケーションで監視されている必要があります。

（注）	会議のチェーニング、またはチェーニングされた電話会議への参加者の追加が関わる会議のシナリオでは、JTAPI は ConferenceStarted/Ended イベントを提供しません。

詳細は、次のトピックを参照してください。

• 「CiscoCall」（getConferenceChain() インターフェイス用）

• CiscoConferenceChain

• CiscoConferenceChainAddedEv

• CiscoConferenceChainRemovedEv

メディア パスを確立せずに転送用のコンサルト コールが実行されていることを、アプリケーションから Cisco Unified Communications Manager に通知できます。実際の転送の前にエージェントが使用可能かどうかを判別するために、コンサルト コールが実行されている場合は、中継コールのためにメディア パスを確立する必要はありません。CiscoConsultCall インターフェイスで定義されている consultWithoutMedia メソッドでは、メディア パスを確立せずにコンサルタント コールが作成されます。

（注）	コンサルト コールは、転送だけが可能です。これは会議には使用できません。

アプリケーションによって登録される CTI Port には、電話機に似たメカニズムがあります。CTIPort へのシグナリングを処理している Cisco Unified Communications Manager に障害が起きると、CTIManager はこのデバイス用のデバイス プール管理に従ってそのサービスを復旧させます。CTIManager の障害時には、CTI Port がバックアップ CTIManager に接続されると、Cisco Unified JTAPI によって CTI Port が再登録されます。CTI Port の復旧後、CiscoAddrOutOfServiceEv イベントおよび CiscoTermOutOfServiceEv イベントと対応するイン サービスのイベントが送信されます。

これらのデバイスに対するメディア ストリーミングは、アプリケーションによって制御され、ポートがアウト オブ サービスの場合でもストリーミングは継続します。新しいコールを受け入れる準備が完了するまで、デバイスに対して新しいコールが発行されないように、アプリケーション側で処理します。

Cisco Unified Communications Manager サーバの障害時には、CTI RoutePoint のデバイス プール管理で定義された Cisco Unified Communications Manager サーバ グループから CTIManager がデバイスを復旧させます。プライマリ Cisco Unified Communications Manager サーバが復旧すると、CTIManager はそのプライマリ Cisco Unified Communications Manager 上のデバイスの復旧を試行します。このリホームは、デバイス上にコールがない場合に行われます（物理デバイスと同様）。

CTIManager の障害時には、Cisco Unified JTAPI がバックアップ CTIManager 上のデバイスを復旧させます。CiscoAddrOutOfServiceEv イベントと CiscoAddrInServiceEv イベントによって、デバイスのアベイラビリティがアプリケーションに通知されます。

携帯デバイスのトレンドの変化と、モバイル ワーカーやリモート ワーカーの増加により、Bring Your Own Device（個人所有デバイスの持ち込み、BYOD）の理念をベースに UC 機能を拡張した、より柔軟なユニファイド コミュニケーション ソリューションの必要性が高まっています。Extend and Connect は、こうした変化に対応します。

Extend and Connect は、あらゆるエンドポイントで相互運用されるユニファイド コミュニケーション（UC）コンピュータ テレフォニー インテグレーション（CTI）アプリケーションを、管理者がすばやく展開できるようにする機能です。Extend and Connect では、あらゆるデバイスであらゆる場所から UC アプリケーションの利点を活用できます。この機能は、新しい UC ソリューションとレガシー システムとの相互運用性を実現し、既存のハードウェアが推奨されなくなった場合でも、段階的に移行を進めることができます。

詳細については、『Cisco Unified Communications Manager Features and Services Guide』を参照してください。

CTI ビデオ サポート機能により、JTAPI アプリケーションは、回線デバイスのマルチメディア機能（ビデオの受信、ビデオの送信、ビデオの送受信など）を検出できます。Cisco JTAPI は、拡張 CTI ビデオ サポートを通じて端末のビデオ機能を公開する機能をアプリケーションに提供します。CTI アプリケーションは、ビデオ対応デバイスとビデオ非対応デバイス、および音声のみのコールとビデオ コールを区別できます。

Cisco JTAPI は、CiscoTerminal にデバイスのマルチメディア機能を公開する getCiscoMultiMediaCapabilityInfo() という新しい API を提供します。Cisco JTAPI は、デバイスが登録状態になった後に、端末のマルチメディア機能を公開します。端末のマルチメディア機能には以下の機能があります。

• ビデオ機能（なしまたはビデオ対応）

• テレプレゼンスの相互運用性（なしまたはデバイスのテレプレセンスの相互運用性が有効）

• 画面の数（デバイスで利用可能な画面を確認する）

マルチメディア機能は新しいインターフェイス CiscoMultiMediaCapabilityInfo で公開され、これらの機能を公開する次の API を持ちます。

• getVideoCapability()、

• getTelepresenceInfo()、

• getScreenCount()。

CiscoCall の次の API は、アプリケーションがメディアをセットアップする前に発信側または着信側のマルチメディア機能を確認するために使用されます。

• getCallingTerminalMultiMediaCapabilityInfo()：コールの発信側

• getCalledTerminalMultiMediaCapabilityInfo()：コールの着信側

端末のビデオ機能が変わると、新しい Cisco JTAPI イベント CiscoProvTerminalMultiMediaCapabilityChangedEv によってアプリケーションに通知されます。このイベントは JTAPI プロバイダー イベントで、アプリケーションがプロバイダー オブザーバを追加すると配信されます。このイベントを受信するには、端末が登録状態であることが必要です。Cisco Camera の着脱はビデオ機能の状態に影響しないため、このイベントはトリガーされません。ただし、Cisco UCM 管理インターフェイス > [デバイス設定（Device Configuration）] ページを使用して、ビデオ機能を変更できます。

（注）	CiscoTerminal の初期のビデオ機能 API は CTI ルート ポイントと CTI ポートでサポートされません。ただし、発信側のビデオ情報は受信できます。

次のデバイスは CTI ビデオ機能をサポートします。

• 89xx（SIP のみ）

• 99xx

• E20

• EX60/90

• CTS 500

• CTS 500-32

• Jabber（CSF）

• CTI RoutePoint

• CTI ポート

CTIManager サービス パラメータ [デバイスの IP アドレッシング モード（IP Addressing Mode for Devices）] が新たに追加されたことで、共通デバイス設定に関連付けられていないデバイスで、デフォルト CTI IP アドレッシング モードを設定できるようになりました。

共通デバイス設定を持たないデバイスでアプリケーションが CiscoTerminal.getIPAddressingMode() メソッドを呼び出すと、JTAPI によりサービス パラメータの値が返されます。新しいサービス パラメータのデフォルト設定は [IPv4 および Pv6（IPv4 and IPv6）] です。JTAPI では、CiscoTerminal.IP_ADDRESSING_MODE_IPV4_V6 を介してこの値を通信します。

（注）	個々の CTI デバイスでは、共通デバイス設定が関連付けられている場合、共通のデバイス設定の IP アドレッシング モード設定が [デバイスの IP アドレッシング モード（IP Addressing Mode for Devices）] サービス パラメータの設定をオーバーライドします。

DeleteCall インターフェイスでは、アプリケーションが、createCall インターフェイスを使用して作成されたコールを削除できるようにします。このメソッドはコールを受け取り、プロバイダーがイン サービスでない場合、またはコールがアイドル状態ではない場合に InvalidStateException をスローします。DeleteCall により、コールが Invalid 状態に移行されます。

次のインターフェイスが CiscoProvider に追加されます。

{ public void deleteCall( Call call ) throws InvalidStateException; }

アプリケーションではこのインターフェイスを使用して、createCall を使用して作成されたコールを削除できます。このメソッドはコールを受け取り、プロバイダーがイン サービスでない場合、またはコールがアイドル状態ではない場合に InvalidStateException をスローします。DeleteCall により、コールが Invalid 状態に移行されます。

コールを正常に削除するには、createCall を使用してアプリケーションでコールを作成し、コールをアイドル状態にする必要があります。

Cisco Unified JTAPI では、デバイスの自動復旧がサポートされています。

Cisco Unified IP Phone 7960 などのデバイスについては、リホーム機能がデバイス ファームウェアの一部に組み込まれています。プライマリ Cisco Unified Communications Manager に障害が発生すると、電話機は通話中でないときにバックアップの Cisco Unified Communications Manager への接続を試行します。この移行は、CTIManager の障害で説明するアウト オブ サービスおよびイン サービスのイベントの形式でアプリケーションに送信されます。

CTI Port や CTI RoutePoint などのファームウェアのない仮想デバイスでは、CTIManager または Cisco Unified JTAPI によってフェールオーバーが実行されます。

回線をまたいで直接転送（Direct Transfer Across Lines）機能により、回線をまたいだ転送をサポートできます。この機能により、電話の [転送（Transfer）] ソフトキーを押すか、Cisco Unified JTAPI で提供されている transfer() API を使用して、同じ端末の異なるアドレスに 2 つのコールを転送できます。回線をまたいだ転送を実行すると、アプリケーションは最終コールとコンサルト コールで共通のコントローラを認識しないため、JTAPI アプリケーションの動作が変わります。API 自体に変更はなく、会議に参加するコールが同じアドレス（通常の転送）か異なるアドレス間（回線をまたいだ直接転送）かどうかに関係なく、同じイベントが配信されます。この機能は、CTI ポート、SCCP デバイス、SIP デバイスなど、サポートされるすべての電話でサポートされています。

JTAPI API から直接転送が試みられている 2 つのアドレスのいずれかにオブザーバが追加されていない場合、Cisco Unified JTAPI は、「転送コントローラが設定されていません。適切な TerminalConnection が見つかりませんでした（Transfer controller is not set and could not find a suitable TerminalConnection）」というエラーと共に PlatformException をスローします。

この機能では、ユーザが自分の選択したパーク コードにコールを転送して、コールをパークできます。

アプリケーションは、デバイス追加、ユーザ コントロール リストからの削除、および Cisco Unified Communications Manager データベースからのデバイスの削除に関する通知を非同期に要求します。また、アプリケーションは回線変更およびデバイスに関する通知を受信します。この通知は Cisco Unified JTAPI に送信され、それぞれ AddressObserver と TerminalObserver 上の CiscoAddrCreatedEv、CiscoAddrRemovedEv、CiscoTermCreatedEv、および CiscoTermRemovedEv によってアプリケーションに伝搬されます。

（注）	回線変更通知を受信するために、CTIPort と CTIRoutePoint に対して必ずデバイスを登録してください。

サイレント（DND）機能を使用すると、電話機のユーザが、電話機を離れるときや、受信コールに応答したくない場合に、電話機を DND 状態にできます。[DND] ソフトキーを使用して、この機能を有効または無効に設定します。

ユーザ ウィンドウから、DND の次の設定を指定できます。

• DND オプション：[呼出音オフ（Ringer Off）]

• DND 着信呼警告：[ビープ音のみ（Beep Only）]/[フラッシュのみ（Flash Only）]/[無効（Disable）]

• DND タイマー：0 ～ 120 分の値。"DND（サイレント）がアクティブであることをユーザに知らせる時間（分単位）"を指定します。

• DND ステータス：オン/オフ

（注）	アプリケーションからは、DND ステータスを有効または無効に設定することだけが可能です。

• アプリケーションから DND ステータスを設定するには、CiscoTerminal で新しいインターフェイスを呼び出します。

• DND ステータスが電話機、Cisco Unified Communications Manager Administration、またはアプリケーションによって設定されると、JTAPI も DND ステータスの変更をアプリケーションに照会します。

• アプリケーションでは、事前の通知を受信するためには、CiscoTermEvFilter のフィルタを有効にする必要があります。

• アプリケーションでは、CiscoTerminal の新しいインターフェイスから、DND ステータスも照会できます。

• アプリケーションでは、CiscoTerminal の新しいインターフェイスから、DND オプションも照会できます。

（注）	この機能は、電話機と CTI ポートに適用できます。ルート ポイントは該当しません。

Cisco Emergency Responder（CER）アプリケーションが発信した緊急コールが、DND が有効になっているアプリケーションに着信すると、DND 設定が無効になり、コールがアプリケーションに繋がれます。CiscoCall、CiscoConnection および CiscoRouteSession の redirect() および selectRoute() API に含まれる FeaturePriority という新しいパラメータにより、この機能が提供されます。緊急コールを発信する CER アプリケーションにより、FeaturePriority が FeaturePriority_Emergency に設定されます。アプリケーションが feature priority を設定するのは、緊急コールだけです。通常のコールの場合、アプリケーションは feature priority をまったく設定しないか、または FeaturePriority_Normal に設定します。通常のコールで、アプリケーションが FeaturePriority_Emergency に設定することはありません。インターコムなどの機能コールを発信する場合、アプリケーションは FEATUREPRIORITY_URGENT を設定する必要があります。

（注）	CiscoCall の connect() API では FeaturePriority パラメータをサポートしていません。

デバイスがイン サービスになる前に getDNDStatus()、setDNDStatus() または getDNDOption() を実行すると、アプリケーションに例外が返されます。

setDNDStatus() 要求の送信後に発生した DB アップデートの失敗またはデバイスのアウト オブ サービスの状況に対処するために、DND（サイレント）に事後条件が追加されます。setDNDStatus() 要求の送信後に DB アップデートの失敗またはデバイスのアウト オブ サービスの状況が発生すると、setDNDStatus() によってアプリケーションに CiscoTermDNDStatusChangedEv が配信されます。このイベントを受信しなかった場合、事後条件によるタイムアウトが発生し、setDNDStatus() のポスト コンディションに一致しなかったことを示す例外がスローされます。

Do Not Disturb–Reject（DND–R）は、既存のサイレント（DND）機能の拡張機能です。これまで、Cisco Unified Communications Manager と JTAPI では、呼出音をオフにする DND（サイレント）機能だけがサポートされていました。ユーザは DND–Reject を使用してコールを拒否できます。DND–R は、Cisco Unified CM の管理ページの電話の設定ウィンドウ、または電話プロファイルの設定ウィンドウから設定できます。

DND–R が有効である場合、コール拒否が有効な端末にコールは表示されません。つまり、そのエンド ポイントには、着信コールを示す音声または視覚的な表示は行われません。DND–R を有効にするには、DND のステータスを true に設定し、DND オプションを [コール拒否（Call Reject）] に設定します。

FeaturePriority により DND が上書きされます。次のいずれかの値が返されます。

• 1: Normal

• 2: Urgent

• 3: Emergency

このリリースでは、CiscoCall の connect() API に FeaturePriority が導入されました。selectRoute() と redirect() API の FeaturePriority は、以前のリリースからすでにサポートされています。connect() API で機能プライオリティが EMERGENCY に指定されており、宛先の端末で DND–R が有効である場合、宛先端末にコールがあると呼出音が鳴り、DND–R 設定が上書きされます。

端末で DND–R が有効であり、インターコム コールを受信すると、DND–R 設定は上書きされ、コールが表示されます。これは、インターコム コールの機能プライオリティは、必ず 2（URGENT）に設定されているためです。

A が B をコールし、端末 B で DND–R が有効な非共有回線のシナリオでは、USER_BUSY が原因の CallCtlConnFailedEv が A に配信されます。共有 DN を持つすべての端末で DND-R が有効になっている場合、ユーザは同じ動作を経験します。

共用回線の 1 つ以上の端末で DND–R が無効であり、その共用回線にコールが発信されると、Cisco Unified JTAPI により、DND–R が有効に設定されている端末に対して TermConnPassiveEv と CallCtlTermConnInUseEv が配信されます（コールの機能プライオリティが NORMAL に設定されていると仮定した場合）。端末上で DND–R が無効である場合は、コール時に、TermConnPassiveEv と CallCtlTermConnBridgedEv が配信されます。

Cisco Unified CM の管理ページの電話の設定ウィンドウまたは電話プロファイルの設定ウィンドウで DND（サイレント）オプションが変更されると、新しいイベントである CiscoTermDNDOptionChangedEv が端末オブザーバに送信されます。

デフォルトの DND オプションは [呼出音オフ（Ringer Off）] で、ルート ポイントで DND はサポートされません。

この機能は、任意の参加者を電話会議から終了させる機能です。Cisco Unified JTAPI により、アプリケーションが接続のためにアドレスを監視していない場合でも、既存のインターフェイス Connection.disconnect() を使用して、参加者を会議から終了させることができます。これまで、アプリケーションでは、アドレスが監視対象のアドレスである Connection だけを切断できました。

機能の動作は、Cisco Unified Communications Manager サービス パラメータ Advanced Ad Hoc Conference Enabled の設定に基づいて異なります。このサービス パラメータが False に設定されている場合、アプリケーションは会議コントローラのアドレスを監視している場合に限り、電話会議の監視していないアドレスの Connection を終了できます。このパラメータが True に設定されている場合、アプリケーションは無制限で Connection を終了できます。

Cisco Unified JTAPI は、CiscoConnection で、Connection のための CiscoPartyInfo オブジェクトの配列を取得するインターフェイスを提供します。CiscoPartyInfo は、CiscoConnection で提供されている新しいインターフェイス disconnect() を使用して、参加者を会議から切断させることができます。通常の回線では、その Connection に CiscoPartyInfo が 1 つしかありませんが、共用回線には、共用回線の回線ごとに 1 つの CiscoPartyInfo があります。これにより、電話会議に複数の共用回線の参加者がいる場合に、アプリケーションは共用回線の参加者を選択して切断できます。共用回線の参加者の Connection は 1 つしかないため、アプリケーションで既存の Connection.disconnect() API を使用した場合、すべての共用回線の参加者が切断されます。

Cisco Unified JTAPI では、CiscoJtapiProperties で、この機能を有効または無効にするインターフェイス setDropAnyPartyEnabled() を提供しています。デフォルトでこれは有効になっています。または、アプリケーションは、jtapi.ini ファイルの JTAPI ini パラメータ dropAnyPartyEnabled = 0 を使用して、任意の通話者のドロップ（Drop Any Party）機能を無効にし、dropAnyPartyEnable = 1 を使用して、この機能を有効にできます。jtapi.ini ファイルに dropAnyPartyEnable パラメータが存在しない場合、この機能はデフォルトで有効になります。

Cisco Unified JTAPI では、CiscoCall で、コールが電話会議であるかどうかを判断するためのインターフェイス isConferenceCall() も提供しています。この簡単なメソッドはブール値を返します。

この機能により、コールごとに、またはメディアが確立されるたびに、アプリケーションから IP アドレス（ipAddress）およびポート番号（portNumber）を提供することが可能になります。この機能を使用するには、メディア機能を提示して、アプリケーションでメディア端末を登録する必要があります。このメディア端末でコールが応答されると、アプリケーションに CiscoMediaOpenLogicalChannelEv が送信されます。このイベントは、メディアが確立されるたびに送信されます。アプリケーションはこのイベントに応答し、メディアが確立される IP アドレスとポート番号を示す必要があります。

CiscoMediaTerminal は、アプリケーションによる RTP メディア ストリームの終端を可能にする、特殊な CiscoTerminal を表します。CiscoMediaTerminal は、通常の CiscoTerminal と異なり、物理的なテレフォニー エンドポイントではないため、サードパーティ方式で監視、制御することができます。CiscoMediaTerminal は論理的なテレフォニー エンドポイントを表し、メディアを終端するアプリケーションに関連付けることができます。そのようなアプリケーションには、音声メッセージング システム、音声自動応答装置（IVR）、ソフトフォンなどが含まれます。

（注）	Cisco Unified JTAPI により CiscoMediaTerminal として表現されるのは、CTIPort だけです。

メディアの終端プロセスには 2 つの段階があります。アプリケーションはまず、特定の端末向けのメディアを終端するために、Terminal.addObserver メソッドを使用して、CiscoTerminalObserver インターフェイスを実装するオブザーバを追加します。次に、CiscoMediaTerminal.register メソッドを使用して、その IP アドレス、およびその端末向けの着信 RTP ストリームの送信先となるポート番号を登録します。

コールごとに動的に ipAddress および portNumber を登録するには、アプリケーションは、サポートしている機能だけを提示して登録する必要があります。アプリケーションは、メディアが確立されるたびに送信される CiscoMediaOpenLogicalChannelEv に応答する必要があります。アプリケーションが CiscoMediaOpenLogicalChannelEv に応答する前に何らかの機能が実行された場合、機能が失敗する可能性があります。

[Cisco Unified Communications Manager Administration] ウィンドウにある Media Exchange Timer に指定された時間内にアプリケーションがこのイベントに応答しない場合、コールが失敗する可能性があります。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。コールごとの CTIPort 動的登録のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

（注）	ChangeRTPDefaults インターフェイスは CiscoMediaTerminal ではサポートされていません。

コールごとの CTIPort 動的登録には、次の新しいインターフェイスまたは変更されたインターフェイスがあります。

この機能は、テレワーカーやオフプレミス ユーザが構外から緊急コールを発信できるように、これらのユーザにロケーション認識を提供することを目的として開発されました。API のこの機能は、次のような一般的な方法で、すべてのアプリケーションで使用できます。

最初にこの機能は、既存のパラメータ リストに XML パラメータを追加するためにオーバーロードされる 2 つの JTAPI API メソッド（selectRoute と redirect）を追加します。すべてのアプリケーションで、オーバーロードされたこれらの selectRoute() および redirect() メソッドを使用して、コールの着信側に XML データを渡します。渡すことができる XML データの形式は次のとおりです。

<data> <item> <type>contact</type> <operation>append</operation> <protocol>SIP</protocol> <value>;+sip.instance = "<urn:uuid = *guid*>"</value> </item> </data> 

アプリケーションが上記の API のいずれかを使用して XML データを送信すると、CTI はそのデータを解析し、XML の値のノードからテキストを抽出して CCM に渡します。CCM はこのテキストを発信の SIP INVITE メッセージの「contact」ヘッダーに追加します。SIP トランクまたは SIP フォンなどのエンド ポイントでは、このメッセージを受信した後、contact ヘッダーからデータを抽出して処理できます。現在、SIP プロトコルの contact ヘッダー フィールド データのみがサポートされていますが、今後のリリースでは、他のヘッダー フィールドやその他のプロトコルを含むように拡張されます。

CUCM の現在のバージョンでは、次の XML ノードの値のみがサポートされています。type: contact、operation: append、protocol: SIP。上記の XML 形式の value ノードは、必要なアプリケーション データをエンド ポイントに伝送する例を示しています。

新しいパラメータは、選択された各ルートの XML データを格納できる、オーバーロードされた selectRoute() メソッドの 2 バイト配列と、redirect() メソッドの 1 バイト配列です。パラメータは、XML 形式の文字列値または NULL 値をとります。

CiscoAddress の拡張により、デバイス上のすべての回線に対する呼び出し音のステータスをアプリケーションによって設定できます。管理用ウィンドウやその他のウィンドウから呼び出し音の設定が変更されても、イベントは生成されません。

この機能を使用すると、アプリケーションで任意のコールを個別にトレースできます。JTAPI では、UniqueID が各 Connection オブジェクトに関連付けられます。インターフェイス CiscoConnection では、新しい API getUniqueID(Terminal term) 経由で同じ ID がアプリケーションに公開されます。この UniqueID は、監視対象アドレスの Connection でのみ使用できます。

Connection が作成されるときに、アプリケーションでは、UniqueID を受信し、それをコール詳細レコードに書き込みます。共用回線シナリオでは、各共用回線が UniqueID を持ち、これは、対応する Terminal を getUniqueID API に渡すことによって取得できます。UniqueID はシナリオによって、異なる共用回線で同じになる場合と同じにならない場合があります。アプリケーションでは、その共用回線端末で TermConnActiveEv を受信するときに、各共用回線に対して UniqueID を照会できます。

UniqueID が変更されるたびに、JTAPI により、アプリケーションのコール オブザーバに CiscoConnectionUniqueIDChangedEv が配信されます。

（注）	リリース 8.0(1) の時点では、JTAPI によってアプリケーションに CiscoConnectionUniqueIDChangedEv イベントが配信される使用例はありません。

この機能により、EnergyWise が有効なシステムに、電話機で参加できます。電話機の電力使用率が、電話機から EnergyWise 準拠スイッチに通知され、カスタマーの建物内の電力のトラッキングと制御ができます。電話機は、消費電力がきわめて低いオフ モードなどの、代替電力低減モードを提供します。Cisco Unified Communications Manager 管理者は、Cisco Unified CM の管理ページのベンダー固有の設定を使用して、電話機の電力状態を設定し、排他的に管理します。

EnergyWise スイッチとのネゴシエーション後に電話機の電源オフ時間になると、Cisco Unified CM から登録解除し、Deep Sleep/PowerSavePlus モードに移行します。電話機は、Deep Sleep モードが設定した電源オン時間に達すると自動的に Cisco Unified CM に再登録します。

Deep Sleep/PowerSavePlus モード中に Cisco Unified IP Phones シリーズの 9900 および 6900 の [選択（Select）] キーを押して、電話を起動することができます。これらの電話では自動的に電源がオンになり、Cisco Unified CM に再登録されます。ただし、Cisco Unified IP Phones 7900 シリーズの電話の場合、"PowerON" 時間に達するまで、Deep Sleep/PowerSavePlus モード中に電源をオンにしたり、Cisco Unified CM に再登録したりすることはできません。Deep Sleep モードは、Cisco Unified CM のデバイス ページで設定できます。電話機の Deep Sleep モードを、実際の電源オフの時間よりも 10 分以上前に設定すると、スイッチと電話機間で情報を同期できます。

電源オフ アイドル タイマーは、電話で物理的な操作が発生した場合のみ有効になります。たとえば、EnergyWise が設定された電話機に、Deep Sleep 移行中にコールがあり、ユーザがアプリケーションからコールを切断すると、電源オフのアイドル タイマーが 10 分にデフォルト設定されますが、ユーザが電話機から手動でコールを切断すると、電源オフのアイドル タイマーは Cisco Unified CM のデバイス ページで設定された値をとります。

端末が Cisco Unified CM への登録を解除すると、JTAPI は、新しい理由コード「CiscoProvterminal UnRegisteredEV.ENERGYWISE_POWER_SAVE_PLUS」とともに、アプリケーションに CiscoProvTerminalUnRegisteredEV" "イベントを送信します。

設定された Deep Sleep モードのために端末がサービスを停止すると、JTAPI は、理由「CiscoOutOfServiceEv.CAUSE_ENERGYWISE_POWER_SAVE_PLUS」とともに、CiscoTermOutOfServiceEv イベントをアプリケーションに送信します。" "

設定された Deep Sleep モードのためにアドレスがサービスを停止すると、JTAPI は、新しい理由コード「CiscoOutOfServiceEv.CAUSE_ENERGYWISE_POWER_SAVE_PLUS」とともに CiscoAddrOutOfServiceEv イベントをアプリケーションに送信します。" "

Sample Code:public class MyTermObserver implements ProviderObserver { public void providerChangedEvent (ProvEv[] evlist) { for(int i = 0; evlist ! = null && i < evlist.length; i++){ … … If ( evlisth[i] instanceof CiscoProvTerminalUnregisteredEv){ CiscoProvTerminalUnregisteredEv ev = (CiscoProvTerminalUnregisteredEv)evlist[i]; if(ev.getReason() = = CiscoProvTerminalUnregisteredEv.ENERGYWISE_POWER_SAVE_MODE){ System.out.println(“Terminal Unregistered from CUCM because of deep with the reason as ENERGYWISE_POWER_SAVE_PLUS ”); }  

この機能を使用すると、ユーザは、別のクラスタで設定されたユーザ プロファイルを使用してクラスタに登録されている IP フォンにログインできます。エクステンション モビリティ機能を使用すると、ユーザは管理ポリシーに従い、IP フォンにログインでき、その電話はユーザの席の電話として一時的に動作します。IP フォンにログイン後、ユーザは自分の席に通常ルーティングされる着信コールを受信でき、短縮ダイヤル、サービス リンク、その他のユーザ固有のプロパティなどの個人設定を保持できます。

現在は、エクステンション モビリティ サービスは、Cisco Unified Communications Manager（Cisco Unified Communications Manager）クラスタに制限されています。現在、1 つのクラスタでプロビジョニングされているユーザは、両方のクラスタが同じ企業に属している可能性がある場合でも、エクステンション モビリティ機能が使用されている別のクラスタの IP フォンにはログインできませんでした。この新機能を導入するとこの制限がなくなり、1 つのクラスタでプロビジョニングされているユーザが、別のクラスタの IP フォンにログインできます。

現在の動作では、Cisco Unified Communications Manager JTAPI アプリケーションで使用されているユーザ ID と同じ ID を使用してユーザがログインすると、その端末はコントロール リストの一部として扱われ、アプリケーションは端末やアドレス上でコール オブザーバを追加することができます。

この機能サポートの一部として、Cisco Unified Communications Manager の管理ページを利用して、エクステンション モビリティのプロファイルをユーザのコントロール リストに追加することができます。ユーザが、エクステンション モビリティで、コントロール リストにあるプロファイルを使用してデバイスにログインすると、JTAPI により、CiscoAddrCreatedEv および CiscoTermCreatedEv が配信され、アプリケーションでは、コール オブザーバを追加して端末またはアドレスを制御できます。

JTAPI により、すべてのプロバイダー イベントで getCiscoCause () API が公開されます。エクステンション モビリティ以外のログインまたはログアウトに関連するプロバイダー イベントでは、配信される原因は CiscoProvEv.NORMAL です。エクステンション モビリティのログインまたはログアウトに関連するプロバイダー イベントでは、ログインまたはログアウトのタイプに応じて、原因は次のいずれかとなります。

CiscoProvEv.CAUSE_EM_LOGIN CiscoProvEv.CAUSE_EM_LOGOUT CiscoProvEv.CAUSE_EM_LOGIN_PROFILE_ADD CiscoProvEv.CAUSE_EM_LOGOUT_PROFILE_REMOVE 

インターフェイスの変更により、それぞれの原因がより詳しくわかります。

API getCiscoCause() を含むプロバイダー イベントの完全なセットは、次のとおりです。

CiscoAddrActivatedEvCiscoAddrActivatedOnTerminalEv CiscoProvFeatureEv CiscoProvTerminalCapabilityChangedEv CiscoAddrRestrictedEv CiscoTermActivatedEv CiscoTermRestrictedEv CiscoAddrCreatedEv CiscoTermCreatedEv CiscoAddrRemovedEv CiscoTermRemovedEv CiscoAddrAddedToTerminalEv CiscoAddrRemovedFromTerminalEv. 

JTAPI により CiscoTerminal での getLoginType () が公開され、ユーザがエクステンション モビリティのログインまたはログアウトを行ったときに、その端末がホーム クラスタの一部であるか Visiting クラスタの一部であるかが示されます。これに従って、戻り値は CiscoTerminal.NO_LOGIN、CiscoTerminal.NATIVE_LOGIN、または CiscoTerminal.VISITOR_LOGIN になります。

ホーム クラスタは Cisco Unified Communications Manager のクラスタであり、移動中の EMCC ユーザはここからスタートします。ユーザのユーザ プロファイルが存在するのがホーム クラスタです。

Visiting クラスタは、移動中の EMCC ユーザが訪問する先の Cisco Unified Communications Manager クラスタです。ユーザがエクステンション モビリティ ログインを実行する電話機があるクラスタです。

エクステンション モビリティのログイン ユーザ名機能を使用すると、アプリケーションは CiscoTerminal で提供された API からエクステンション モビリティのログイン ユーザ名を取得できます。

外部コール制御を使用すると、Cisco Unified Call Manager（Cisco Unified Communications Manager）は、エンタープライズ ポリシー、および個々のユーザのプレゼンスベースのルーティング ルールに基づいてコールをルーティングできます。コールの代行受信が有効の場合、Cisco Unified Communications Manager は、指定された Web サービス ホスティングにエンタープライズ ポリシーまたはユーザ ルールを照会し、返されたルーティングの決定に従ってコールをルーティングします。

リリース 8.0(1) から、JTAPI では、トランスレーション パターンだけではなくワイルドカード ルートポイントもサポートされます。

Cisco Unified Communications Manager はコールの各レッグに固有のセッション識別子を生成します。この機能により、アプリケーションは固有のセッション ID を使用してコールのエンド ツー エンドの追跡を行うことができます。

メソッドはパラメータとしてその接続に関連付けられた TerminalConnection オブジェクトを受け取り、指定の CiscoConnection のローカルとピアそれぞれの参加者の UUID を表す文字列を返します。Null オブジェクトがパラメータとして渡される場合、メソッドは CiscoConnection のアクティブな TerminalConnection の UUID を返します。

device=<localUUID>;remote=<peerUUID>;

非 SIP デバイスではセッション ID はCisco Unified Communication Manager 内で生成されます。SIP デバイスは独自のセッション ID を生成し、SIP INVITE メッセージで Cisco Unified Communication Manager に公開します。この情報は、各インターフェイスを通じてアプリケーションに表示されます。

CiscoCall の CiscoConnection のローカル ユニバーサル ユニーク ID（localUUID）は CiscoCall の反対側の peerUUID で生成され、逆も同様に生成されます。

シスコのコールが複数のデバイス間で共有される場合、受信側の CiscoConnection が CiscoConnection.ALERTING 状態にあるときでも、発信側の CiscoConnection.getPeerUUID(null) は使用可能な端末の UUID を返します。コールに応答があると、発信側の CiscoConnection.getPeerUUID(null) はアクティブな TerminalConnection の uuid を返します。

この機能を使用すると、Cisco Unified Communications Manager を連邦情報処理標準（FIPS）モードで動作させることができます。FIPS では、暗号関数の最小セキュリティ レベル、データの保存方法に関する制限、および機密情報の暗号化に使用できるアルゴリズムを指定します。この厳密に定義された要件は、行政機関、病院、その他の高度なセキュリティを必要とする顧客にとって重要です。

FIPS 準拠を有効にするには、Cisco Unified Communications Manager アプリケーションは JTAPI で証明書をダウンロードするときと、プロバイダーを開くときに、このモードを要求する必要があります。FIPS での動作中、Cisco Unified Communications Manager のパフォーマンス ロスは最小限に抑えられ、そのロスは証明書のダウンロード中および JTAPI プロバイダーを開く場合にのみ認識されます。アプリケーションを実行した後は、FIPS の影響はまったくありません。

リリース 8.6(1) から、JTAPI を FIPS 準拠として設定できます。

強制承認コード（FAC）は、外線、市外通話、国際通話など、特定のクラスのダイヤル番号（DN）にコールを発信する前に有効な認証コードの入力をユーザに要求します。ライセンス情報は、Cisco Unified Communications Manager の CDR データベースに書き込まれます。

クライアント識別コード（CMC）は、コールを発信する前にユーザがコードを入力できるようにします。クライアント識別コードを使用すると、発信したコールに会計コードや請求コードを割り当てることができます。クライアント識別コードの情報は、Cisco Unified Communications Manager の CDR データベースに記録されます。

この機能では、帯域幅不足および未登録 DN 発生時に対処するために、転送ロジックが次のように拡張されています。

• 帯域幅不足：帯域幅不足のためにコールをリモートの宛先に配信できない場合、コールは AAR 宛先マスクまたはボイスメールに再ルーティングされます。これらの設定は、Cisco Unified Communications Manager GUI の [電話番号（Directory Number）] ウィンドウでユーザが変更できます。

• 未登録 DN：コールが未登録 DN に対して発信されると、コールは無応答時コール転送（CFNA）に設定されている DN に配信されます。

Call Forward No Bandwidth（CFNB）のためにコールが Q Signaling（QSIG）を使用するトランク/ゲートウェイを介して別の着信先クラスタに転送された場合、コールの履歴が失われる可能性があります。たとえば、電話 A から帯域幅の少ない地域にある電話 B をコールし、CFNB でコールを別のクラスタにある電話 C に転送するように設定されている場合、クラスタ間の転送に QSIG 使用されていると、元の着信側と最後にリダイレクトした通話者は着信先に伝達されない可能性があります。

GetCallID では、発信側や着信側などの任意のコール情報にアクセスし、アプリケーション側からコールの RTP イベントにリンクできるように、RTP イベント上のインターフェイスを提供します。

CTIManager からの RTP イベントで受信される callLegID は、クライアント側の ICCNCall の決定に使用されます。このコールは、JTAPI 層に渡され、CiscoCallID の取得元から CiscoCall が判定されます。この情報は、アプリケーションに配送される RTP イベントを構築するために使用されます。

次のインターフェイスが、CiscoRTPInputStoppedEv、CiscoRTPInputStartedEv、CiscoRTPOutputStoppedEv、および CiscoRTPOutputStartedEv に追加されます。

{ public CiscoCallID getCallID();

}

アドレス上の GetCallInfo インターフェイスでは、アドレスに関する CallInfo をアプリケーションによって問い合わせることができます。問い合わせは、CiscoAddressCallInfo オブジェクトを返します。これには、アクティブまたは保留のコールの数、アクティブまたは保留のコールの最大数、およびこのアドレスでの現行コールのコール オブジェクトに関する情報が含まれます。このインターフェイスは、どんなコールが特定の時刻に特定のアドレスにあるかも示します。

次のインターフェイスを使用して、端末に存在するコールに関する情報を取得します。

{ public CiscoAddressCallInfo getAddressCallInfo(Terminal iterminal);}

GetGlobalCallID では、CiscoCallID 上で、コールの nodeID およびグローバル コール ID（GCID）を取得するインターフェイスを提供します。これは内部コール オブジェクトにある GCID 情報を公開します。

次のメソッドが、CiscoCallID インターフェイスに追加されます。

{ /** * returns the callmanager nodeID of the call */ public int getCallManagerID(); /** * returns the GlobalCallID of the call */ public int getGlobalCallID (); }

}

ヘアピン コールは、1 つのクラスタを離れゲートウェイを経由して他のデバイスに発信されたコールが、同じクラスタのデバイスに戻ってきたときに発生します。どちらのコールも同じクラスタ内にありますが、クラスタに戻ってきたコールの GCID とコールを発信した元の GCID は異なります。以前のリリースでは、両方が JTAPI で制御されている場合は、2 つの Connection（CiscoAddress.Internal の Connection と CiscoAddress.External の Connection）がありました。

JTAPI では、アプリケーションがヘアピン コールの両端をモニタする場合に、ヘアピン コールがサポートされます。以前はアドレスが DN だけで表現されていたため、ヘアピン コールの一端しかモニタできませんでした。

現在のリリースでは、DN が同じ 2 つのアドレスが存在し、一方が同じクラスタ内にあり、他方がゲートウェイを経由する場合に、JTAPI により外部 DN に対して別々のアドレス オブジェクトが作成され、アドレスのタイプごとに Connection が 1 つだけ返されるようになっています。以前のリリースではアドレスが常に DN で表されており、アプリケーションでアドレスの Connection を取得すると 2 つの Connection を取得していましたが、このプロセスによりヘアピンの問題が回避されます。

これらの問題を個別に解決すると以前のリリースとの互換性に問題が生じるおそれがあるため、このリリースにはこれらの問題に対処するための包括的なソリューションが組み込まれています。モニタ対象のローカル通話者と同じ DN を持つ外部通話者に関連するコールについては、適切にサポートされるようになりました。ただし、この機能に対応した新しいインターフェイスは追加されていません。

現在、JTAPI メディア イベントの CiscoRTPInputStarted、CiscoRTPOutputStarted、CiscoRTPInputStopped、および CiscoRTPOutputStopped では、メディアが半二重（受信専用/送信専用）か全二重（受信と送信の両方）かは示されません。

この機能拡張により、JTAPI メディア イベントでこの情報を提供する機能が追加されます。JTAPI では、上記のメディア イベントでメディアが半二重か全二重かを問い合わせるインターフェイスが提供されています。

半二重メディアのサポート機能は JTAPI の下位互換性に影響を与えることはありません。

新しいインターフェイス getMediaConnectionMode() が Cisco Unified JTAPI の RTP イベントに追加されています。このインターフェイスはメディアに応じて次の値を返します。

• CiscoMediaConnectionMode.NONE

• CiscoMediaConnectionMode.RECEIVE_ONLY

• CiscoMediaConnectionMode.TRANSMIT_ONLY

• CiscoMediConnectionMode.TRANSMIT_AND_RECEIVE

CiscoRTPInputStarted/StoppedEv は、RECEIVE_ONLY および TRANSMIT_AND_RECEIVE だけを返す必要があります。通常、NONE または TRANSMIT_ONLY が返されることはありません。返された場合は、イベントを無視するか、エラーを記録してください。

CiscoRTPOutputStarted/StoppedEv は、TRANSMIT_ONLY および TRANSMIT_AND_RECEIVE だけを返す必要があります。通常、値 NONE または RECEIVE_ONLY が返されることはありません。返された場合は、イベントを無視するか、エラーを記録してください。

CiscoMediaOpenLogicalChannedEv は、RECEIVE_ONLY および TRANSMIT_AND_RECEIVE だけを返す必要があります。通常、値 NONE または TRANSMIT_ONLY が返されることはありません。返された場合は、イベントを無視するか、エラーを記録してください。

public interface CiscoRTPInputStartedEv

public interface CiscoRTPOutputStartedEv

public interface CiscoRTPInputStoppedEv

public interface CiscoRTPOutputStoppedEv

保留の復帰機能では、アプリケーションに通知が送信されます。この通知には、保留中のコールの存在を Cisco Unified Communications Manager がアドレスに通知するものと、コールが一定時間 ONHOLD 状態であることを通知するものがあります。アプリケーションは、コールを ONHOLD にしたアドレスのコール オブザーバ上で、この通知を CiscoCallCtlTermConnHeldReversionEv Call ControlTerminalConnection イベントとして受信します。この通知は、保留中のコールについて 1 回だけアプリケーションに送信されます。

イベントは、コールが保留された端末の TerminalConnection にだけ送信されます。アドレスが共用回線のアドレスである場合、共用回線アドレスの他の TerminalConnection はイベントを受信しません。

このイベントを受信するには、アプリケーションはアドレスにコール オブザーバを追加する必要があります。このイベントの原因は CAUSE_NORMAL です。保留復帰タイマーの期限が切れて、通知が電話機に送信された後にコール オブザーバが追加された場合、アプリケーションには原因 CAUSE_SNAPSHOT で CiscoCallCtlTermConnHeldReversionEv が送信されます。

詳細については、「CiscoCallCtlTermConnHeldReversionEv」を参照してください。

この機能を使用すると、HuntList LineGroup メンバであるアドレスおよび端末を JTAPI アプリケーションで監視できます。コールは、発信側の別のアドレスから直接または HuntPilot を介して、これらのアドレスに到達します。HuntPilot に対してコールが行われると、JTAPI では、HuntPilot を表す CiscoHuntConnection が作成され、HuntPilot 経由でルーティングされるコールの情報をアプリケーションに渡すコール モデルが提供されます。HuntPilot 経由でコールがルーティングされ、LineGroup メンバに接続されると、JTAPI コールには、3 つの Connection が作成されます。2 つは、発アドレスと着アドレスの通常 Connection で、1 つは、コールがルーティングされた HuntPilot への CiscoConnection です。

HuntPilot は、監視可能なアドレスではありません。ハント パイロットを表すアドレスは、ハント パイロットにコールが行われるときに作成され、コールの終了時に削除されます。アプリケーションは、getAddress() メソッドを使用することによっては、プロバイダーからハント パイロットのアドレスは受信できません。

通常のハント リスト コールには、発信側、ハント パイロット、およびハント メンバの 3 つの Connection があります。ハント パイロットの電話番号をコールする場合、コールは、アルゴリズムによって、そのメンバの 1 つに渡されます。コールの初期状態は、メンバでは Offering です。メンバが監視されていない場合、ハント パイロットへの Connection は、CallCtrlConnection または Connection として通常の状態遷移をします。メンバが監視されている場合、メンバへの Connection は Offering 状態になり、ハント パイロットへの Connection は Established 状態になります。アプリケーションでコールの状態を追跡するには、監視対象の状態を使用する必要があります。

ハント パイロットへのコールの call.getCurrentCalledParty() は、タイプ CiscoAddress.HUNT_PILOT のアドレスを返します。ハント リスト メンバが着アドレスで、アプリケーションによって監視されない場合、コールに応答したときにのみ、メンバへの Connection が作成されます。

CiscoHuntConnection は、CallControlConnection を拡張しており、CallControlConnection が遷移できる状態になるため、ネットワーク状態が想定される場合があります。

ハント パイロットは、CiscoAddress オブジェクトによって表され、getType () は、CiscoAddress.HUNT_PILOT を返します。

Cisocall.getCurrentCalledAddres () および CiscoCall.getCurrentCallingAddress () に返されるアドレスだけが、CiscoAddress.HUNT_PILOT タイプを持ちます。

ハント パイロットへのコールが転送動作または会議動作に含まれている場合、CiscoTransferStartEv、CiscoTransferEndEv、CiscoConferenceStartEv、および CicsoConferenceEndEv は配信されません。存続するコールを特定するには、アプリケーションで CiscoCallChangedEv を使用する必要があります。

コンサルト コールまたは最後のコールに CiscoHuntConnection がある場合、アプリケーションは、転送、会議の開始、会議の終了のイベントを受け取れません。

ブロードキャスト モードに設定されている場合、すべてのハント リスト メンバは、同時に呼び出し音を鳴らします。JTAPI では、ハント リスト メンバへの CallConnection および TerminalConnection は、アプリケーションによって監視されているメンバに対してのみ作成されます。

アプリケーションは、CiscoJtapiProperties で、setHuntListFeatureEnabled（ブール値）を使用して、この機能を有効にする必要があります。この機能はデフォルトで無効に設定されており、アプリケーションで setHuntListFeatureEnabled () API を使用して、前述のコール モデルに合わせ、この機能を有効にすることを推奨します。setHuntListFeatureEnabled を使用してこの機能を有効化しない状態でのハント リストの監視はサポートされていません。監視した場合、コール モデルとイベントは一貫性がないものになります。setHuntListFeatureEnabled() を導入することで、ハント リストを使用して、サポートされないコール シナリオを現在使用しているアプリケーションを、既存の機能のままサポートされるモデルに移入できます。

jtapi.ini ファイルに HuntListEnabled = 1 を追加し、アプリケーションを再起動することによっても、この機能を有効に設定できます。

Cisco Unified CM 9.0 では、ハント パイロットを呼び出すコールで接続番号を modifiedCalledAddress として公開するように、ハント パイロットのサポートが拡張されています。

この拡張機能では、ユーザがハント パイロットをコールして、コールがハント メンバ L1 によって応答されると、call.getModifiedAddress() がメンバ L1 のアドレスを返し、call.getCurrentCalledAddress() がハント パイロットのアドレスを返します。コールが応答される前は、これらの値は両方ともハント パイロットのアドレスを返します。

インターコム機能を使用すると、あるユーザが別のユーザをコールした際に、着信側がビジーであるかアイドルであるかにかかわらず、コールが発信側から着信側への一方向メディアによって自動的に応答されます。着信側は、電話機のディスプレイの応答ソフトキー（無印のキー）を押すか、または TerminalConnection で提供されている join() JTAPI API を起動して発信者と会話を始めることができます。電話機上で特に設定されたインターコム アドレスだけがインターコム コールを開始できます。電話機に設定されたインターコム アドレスに対し、Cisco Unified JTAPI によって CiscoIntercomAddress という新しいタイプのアドレス オブジェクトが作成されます。アプリケーションは、CiscoProvider の getIntercomAddresses () インターフェイスを呼び出すことによって、プロバイダーのドメインに存在するすべての CiscoIntercomAddresses を取得できます。

インターコム コールは、Cisco Unified JTAPI インターフェイスから CiscoIntercomAddress.ConnectIntercom () インターフェイスをコールして開始できます。アプリケーションは、このインターフェイスにインターコム ターゲット DN を提供します。インターコム ターゲット DN がアプリケーションによって事前に構成または設定されている場合、アプリケーションは CiscoIntercomAddress.getTargetDN() インターフェイスを呼び出してターゲットの DN を取得できます。そうでない場合、アプリケーションは有効なインターコム ターゲットを提供しないとコールできません。

インターコム コールはインターコム ターゲットで自動応答されます。Cisco Unified JTAPI により、インターコム ターゲットの TerminalConnection/CallCtlTerminalConnection が Passive/Bridged 状態に移行されます。インターコム ターゲットが応答を開始するには、インターコム ターゲットの TerminalConnection に対してアプリケーションが join () インターフェイスを呼び出します。join () が成功すると、インターコム ターゲットの TerminalConnection/CallCtlTerminalConnection は Active/Talking 状態に移行します。インターコム コールの場合、Cisco Unified JTAPI は次のインターフェイスだけをサポートしています。

• Call.drop ()

• Connection.disconnect ()

• CallCtlTerminalConnection.join ()

アプリケーションは、インターコム コールに対して機能操作を実行できません。CiscoIntercomAddress での Connection に対してリダイレクト、コンサルト、転送、会議またはパークを呼び出すと、Cisco Unified JTAPI によって例外がスローされます。また、アプリケーションが CiscoIntercomAddress に対して setForwarding ()、getForwarding ()、cancelForwarding ()、unPark ()、setRingerStatus ()、setMessageWaiting ()、getMessageWaiting ()、setAutoAcceptStatus () または getAutoAcceptStatus () を呼び出すと、例外を受け取ります。

アプリケーションは、提供された API から、設定されたインターコム ターゲットの DN の値および CiscoIntercomAddress のラベルを取得できます。Cisco Unified JTAPI では、デフォルトを返す API と、インターコム ターゲットに現在設定されている値を返す API の 2 種類の API を提供しています。デフォルト値は、Cisco Unified Communications Manager Administration によって事前に設定されているインターコム ターゲットの DN およびラベルです。現在の値は、アプリケーションによって設定されている暫定ターゲットの DN およびラベルです。アプリケーションによって値が設定されていない場合、現在の値はデフォルト値と同じままです。アプリケーションは、CiscoIntercomAddress に対して API setIntercomTarget () を呼び出して、インターコム ターゲットの DN、ラベルおよび Unicode ラベルを設定できます。インターコム アドレスに対してインターコム ターゲット、ラベルおよび Unicode ラベルを設定できるのは、1 つのアプリケーションだけです。2 つのアプリケーションが値を設定しようとすると、最初のアプリケーションが成功し、2 番めは例外を受信します。インターコム ターゲットの DN とラベルが変更されると、Cisco Unified JTAPI は CiscoIntercomAddress に追加された AddressObserver に対して CiscoAddressIntercomInfoChangedEv を提供します。アプリケーションがインターコム ターゲットの DN およびラベルを設定しており、JTAPI または CTI でフェールオーバーまたはフェールバックが発生すると、JTAPI または CTI は、以前に設定されたインターコム ターゲットの DN、ラベルおよび Unicode ラベルを復元します。JTAPI または CTI がインターコム ターゲットの DN、ラベルまたは Unicode ラベルを復元できない場合、Cisco Unified JTAPI によって CiscoIntercomAddress の AddressObserver に CiscoAddrIntercomInfoRestorationFailedEv が送信されます。アプリケーションが失敗するか、何らかの理由でアプリケーションが停止すると、ターゲットの DN、ラベルおよび Unicode ラベルはデフォルトにリセットされます。JTAPI は、CiscoIntercomAddress に対して resetIntercomTarget () インターフェイスを提供して、インターコム ターゲットをリセットします。

自動応答は、CiscoIntercomAddress に対して常に有効になります。アプリケーションから CiscoAddress に対して getAutoAnswerEnabled () メソッドを呼び出すと、特定のアドレスの自動応答機能を取得できます。

インターコムの開始側に一方向メディアで接続されているインターコム ターゲットの場合、デバイスの状態は CiscoTermDeviceStateWhisper に設定されます。これは、端末オブジェクトの新しいデバイス状態です。この状態では、端末は新しいコールを開始したり、新しい着信コールを受けられます。アプリケーションがこのデバイス状態の受信に対してフィルタを有効にしている場合、アプリケーションは CiscoTermDeviceStateWhisperEv を受信します。アプリケーションは、CiscoTermEvFilter に対して setDeviceStateWhisperEvFilter() をコールしてフィルタを有効にできます。DeviceStates の DEVICESTATE_ACTIVE、DEVICESTATE_HELD、DEVICESTATE_ALERTING は、いずれも、DEVICESTATE_WHISPER を無効にします。もし 1 つのコールがアクティブ、保留またはアラート状態で、別のコールが whisper の場合、DeviceState はそれぞれ DEVICESTATE_ACTIVE、DEVICESTATE_HELD または DEVICESTATE_ALERTING になります。

（注）	Cisco Unified JTAPI では、インターコム ターゲットが開始側に応答するために、javax.telephony.TerminalConnection インターフェイスの join() を実装しています。システムでは、CiscoIntercomAddresses だけに対してこのインターフェイスを実装しています。Passive または Bridged 状態の通常の共有回線に対してアプリケーションがこのインターフェイスを呼び出すと、JTAPI によって MethodNotImplimented 例外がスローされます。

ヒント	アプリケーションで制御されているデバイス（端末）にインターコム回線が設定されていない場合、この機能には下位互換性があります。アプリケーションは、アプリケーションで制御されているデバイス（端末）にインターコム回線を設定しないことにより、インターコム機能を無効にできます。

これらのインターフェイスの変更に関する詳細については、次のトピックを参照してください。

• CiscoHuntConnection

• CiscoAddrIntercomInfoRestorationFailedEv

• 関連資料

• CiscoCall

• CiscoProvider

• CiscoTermEvFilter

• CiscoTerminal

• CiscoTerminalConnection

• CiscoTermDeviceStateWhisperEv

Cisco Unified Communication Manager のリリース 6.0(1) では、インターコム機能のサポートが追加されました。インターコム機能には、着信側が音声による一方向の自動応答を受け取る必要があるため、インターコムに共有アドレスを設定できません。ユーザがエクステンション モビリティ（EM）プロファイルを使用してログインした場合、インターコムと共有アドレスとなる可能性があります。そのため、これまでエクステンション モビリティはインターコムでサポートされていませんでした。エクステンション モビリティは幅広く利用されるため、この 1 つの宛先を共有できないというインターコム アドレスの性質は維持すると同時に、エクステンション モビリティによるインターコムのサポートというニーズに対処しています。

この機能には、デフォルトの端末で設定されたインターコム アドレスが必要です。この機能を使用すると、インターコム アドレスを EM プロファイル上で設定できます。インターコム アドレスが設定された EM プロファイルの端末に EM ユーザがログインすると、インターコム アドレスのデフォルトの端末がユーザがログインした端末と同じであるときだけインターコム アドレスを使用できます。インターコム アドレスが端末に設定されていてもインターコム アドレスのデフォルトの端末がその端末でない場合、インターコム アドレスは端末に表示されません。この端末が Cisco Unified JTAPI アプリケーションのコントロール リストに設定されている場合、JTAPI はプロバイダーのドメイン内にインターコム アドレスを作成しません。Cisco Unified JTAPI の観点からは、この機能をサポートするための新しいインターフェイスや変更はありません。ただし、この機能によって、インターコム機能がインターコム アドレス上で動作しなくなるいくつかの移行シナリオが発生します。使用例を参照してください。

この機能は、IPv6 アドレスをサポートし、CiscoUnified JTAPI が CTIManager への IPv6 接続をサポートするように拡張されています。この機能により、Cisco Unified JTAPI アプリケーションは、IPv6 のサポート機能が有効にされ、発信側が IPv6 対応電話を使用している場合に、発信側アドレスとして、IPv6 アドレスを認識することができます。この機能では、次の関数をサポートしています。

• Cisco Unified JTAPI では、CiscoProviderCapabilities インターフェイスで、Cisco Unified Communications Manager の設定で IPv6 がサポートされているかどうかを示す新しい API canSupportIPv6() を公開しています。

• 以前に登録されている設定と現在の設定に不一致がある場合、Cisco Unified JTAPI はメディアまたはルート端末を閉じます。CiscoTermRegistrationFailedEv および新しい原因コード IP_ADDRESSING_MODE_MISMATCH がこのシナリオに従って送信されます。

• 端末の IP アドレス機能は、CiscoTerminal インターフェイスの getIPAddressingMode() によって API に公開されています。IP アドレス機能は、CiscoTerminal/CiscoMediaTerminal および CiscoRouteTerminal で使用できます。

• IPv6 発信側 IP アドレスは、IPv4 対応デバイスの場合に IPv4 アドレスが提供されるのと同様に、CallCtlConnOfferedEv および RouteEvent の Cisco の拡張機能として InetAddress オブジェクトで提供されます。

監視対象のデバイスが IPv6 デバイスの場合に、CiscoRTPOutputStartedEv および CiscoRTPInputStartedEv の RTP アドレスにも IPv6 アドレスがあります。つまり、CiscoRTPInputProperties の API getLocalAddress() と CiscoRTPOutputProperties の API getRemoteAddress() で、IPv6 形式の IP アドレスを返せるようになりました。API は InetAddress オブジェクトを返し、アプリケーションでは、それが Inet4Address のインスタンスであるか、Inet6Address のインスタンスであるかを確認して、IPv4 形式の IP アドレスか、IPv6 形式の IP アドレスかを判断できます。

アプリケーションでは、IP アドレッシング モードを変更したら、デバイスをリセットする必要があります。そうしないと、予想した結果にならないことがあります。

リリース 7.1 より、Cisco Unified JTAPI では、CiscoTerminal で getIPAddressingMode() API を提供しています。CTI ポートおよびルート ポイントの getIPAddressingMode() API もこのリリースからサポートされています。

Cisco Unified JTAPI では CiscoTerminal の同じ API を拡張し、この API は Cisco Unified Communications Manager の管理ページに、IP フォンの設定済みの IP アドレッシング モードを返します。デバイスの登録後に、ユーザが Cisco Unified Communications Manager の管理ページから、IP アドレッシング モードを変更した場合、デバイスをリセットする必要があります。更新された値は、IP フォンのリセット後に限り、Cisco Unified JTAPI で参照可能になります。設定済みの IP アドレッシング モードがデュアル スタックである場合、つまり、IPv4 アドレスと IPv6 アドレスがサポートされている場合、電話はこれらのいずれかまたは両方のアドレスで登録できます。これは、ネットワークのタイプと Cisco Unified Communications Manager の IPv6 のサポートなどの状況によって異なります。したがって、IP アドレッシング モードが IPv4 アドレスと IPv6 アドレスの両方をサポートしている場合は、CiscoTerminal 上の getIPAddressingMode() は CiscoTerminal.IP_ADDRESSING_MODE_IPV4_V6 を返します。

この機能拡張により、iSAC コーデックがサポートされ、アプリケーションでは、iSAC コーデックの機能を使用して、CiscoMediaTerminal または CiscoRouteTerminal を登録できます。このコーデックでは、フレーム サイズとビット レートは可変で、動的に決定されます。これらの値は、アプリケーションでは設定できません。

インターフェイス CiscoRTPInputProperties および CiscoRTPOutputProperties で公開されているビット レートおよび packetSize はこのコーデックで定数にはならないため、コーデック（payloadType）が iSAC の場合は、アプリケーション ロジックでこれらの値に依存しないようにしてください。

Java ソケット接続のタイムアウト拡張機能を使用すると、Cisco Unified JTAPI 仕様を使用して秒単位でタイムアウトを設定できるので、プライマリ CTI マネージャでは、CTIManager への接続遅延を防ぐことができます。デフォルトは 15 秒です。

デフォルトの 15 秒がアプリケーションに受け入れられない場合は、JAVA API のデフォルトである 0 が、通常の JAVA ソケット接続 API に設定されます。

値の範囲は、5 ～ 180 秒です。デフォルトのゼロを設定すると、JAVA のソケット接続はタイムアウトしません。

このバージョンでこの機能を使用すると、アプリケーションは、同じ端末の異なるアドレス上にある 2 つのコールが参加する会議を開くことができます。また、この機能では、アプリケーションはコントローラ以外を使用して、参加者を会議に追加できます。回線をまたいで参加（Join Across Lines）機能は、SIP を実行する CTI 対応の電話ではサポートされません。

回線をまたいで参加（Join Across Lines）機能は、Join Across Lines Policy サービス パラメータをオフにすることで無効にできます。また、会議のチェーニング機能と、コントローラ以外が参加者を会議に追加できる機能は、"Advanced Ad Hoc Conference Enabled" および "Non-linear Ad Hoc Conference Linking Enabled" サービス パラメータを無効にすることで無効にできます。

（注）	回線をまたいで参加（Join Across Lines）機能は、SCCP を実行している電話機でのみサポートされます。

回線をまたいで参加（Join Across Lines）機能を使用すると、回線をまたいで参加をサポートできます。この機能では、電話機の [参加（Join）] ソフトキー、または JTAPI が提供する conference() API を使用して、同じ端末にある異なるアドレス上の複数のコールを会議に参加させることができます。アプリケーションが最終コールとコンサルト コールで共通のコントローラを認識できない場合、JTAPI アプリケーションに対する動作が変わります。

API 自体は変更されず、会議に参加するコールが同じアドレス（通常の会議）か異なるアドレス間（回線をまたいで参加）かどうかに関係なく、同じイベントが配信されます。回線をまたいで参加（Join Across Lines）機能が実行されると、1 つの会議に結合されるコンサルト コールまたは最終コールが存在するコントローラの端末上のすべてのアドレスに、CiscoConferenceStartEv/EndEv が提供されます。

CiscoConferenceStartEv では、conferenceControllerAddress が必ずプライマリ コントローラ アドレスになります。アプリケーションで setConferenceController() API を使用してコントローラを設定できるようになりました。アプリケーションでコントローラが設定されていない場合、JTAPI によって会議に適切なコントローラが検出されます。回線をまたいで参加（Join Across Lines）機能が起動されている場合、アプリケーションでコントローラ アドレスを設定することを推奨します。

オブザーバをコントロール アドレスに追加しないと、アプリケーションでは、CiscoConferenceStartEv の通話中または保留中端末のいずれかの Connection 値が、null 値と認識される可能性があります。このリリースよりも前のリリースでは、アプリケーションが回線をまたいで会議に参加しようとすると、その要求は JTAPI レイヤで失敗していました。このリリースでは、conference() API の実装が強化されたため、最終コールとコンサルト コールに適した TerminalConnection が検出された後はすべての要求がパス スルーします。JTAPI は、コールに関与する複数のアドレスに共通の端末に基づいて、適切な TerminalConnection を検出します。3 つ以上のコールが参加する必要がある場合、異なるアドレス間での複数の会議もサポートされます。5.1.2 リリースの SIP デバイスではこの機能をサポートしていません。SIP デバイスでこの機能が要求された場合、JTAPI により例外（ILLEGAL_HANDLE）がスローされます。

この機能には、インターフェイスの変更はありません。アプリケーションに提供されるイベントによって、動作は変わります。

回線をまたいで参加（Join Across Lines）機能は、CTI でサポートしている SIP 電話機および SCCP 電話機でサポートしています。拡張機能は次のとおりです。

• アプリケーションは、同じ端末上でアドレスが異なる 2 つのコールで会議を開催できます。

• コントローラ以外を使用して会議に参加者を追加できます。

（注）	回線をまたいで参加（Join Across Lines）機能を無効にするには、Join Across Lines Policy サービス パラメータをオフにします。会議のチェーニング機能と、コントローラ以外が参加者を会議に追加できる機能を無効にするには、Advanced Ad Hoc Conference Enabled および Non-linear Ad Hoc Conference Linking Enabled サービス パラメータを無効にします。

アプリケーションから会議要求が発行されたが、選択したコールとアクティブなコールが会議要求に含まれていない場合、次のような動作が発生します。また、この動作は、ユーザが選択したコールが、会議要求には含まれていないが、結果として開催された会議には含まれていた場合にも適用されます。

• 会議が端末の任意のアドレスのコールによって呼び出された場合は、その端末上のアクティブ コールは、必ず結果として開催された会議に追加されます。B1 と B2 アドレスは同じ端末上にあるとします。

  • A --> B1- GC1

  • C --> B1- GC2

  • D --> B2- GC3（アクティブ コール）

  アプリケーションが GC1.conference (GC2) を呼び出した場合、会議要求に D が含まれていなくても、A-B1-C-D（GC1）の会議が開催されます。

  会議が端末の任意の回線上のコールで開催された場合、その端末上のアクティブな電話会議が、結果として開催される会議に追加されます。この場合、アクティブな電話会議が、存続されるコールとなります（アプリケーションにより指定されたプライマリ コールが電話会議ではない場合）。

  この例では、会議の動作が開始されると、アプリケーションが指定したプライマリ コールはクリアされます。アプリケーションが指定したプライマリ コールが、結果として開催された会議に参加できない場合があります。この場合、会議が終了してもプライマリ コールはクリアされません。

• B1 と B2 のアドレスが同じ端末上にあり、conf1 は、B1 をコントローラとする A-B1-C の会議との電話会議であるとします。

  • B1 --> D – GC1（保留）

  • conf1 – GC2（アクティブ コール）

  • B2 --> E – GC3（保留）

  アプリケーションは GC1.conference(GC2, GC3) を呼び出します。これにより、GC2 が存続するコールとなる A-B1-C-D-E の会議が開催されます。アプリケーションは GC1 をプライマリ コールに指定していましたが、会議の終了後は GC1 は存続しません。

この動作は、通常のコントローラで開催される定例会議にも適用されます。A、B、C、および D が異なる端末上に存在するとします。

• A --> B - GC1

• C --> - GC2

• D --> - GC3（アクティブ コール）

アプリケーションから GC1.conference (GC2) が要求されます。これにより、GC1 で A-B-C-D の会議が開催されます。D とのダイレクト コールが会議要求に含まれていなくても、D は会議に参加できます。

このリリースの Cisco JTAPI クライアントは JRE 1.4、1.5、1.6 だけをサポートします。インターフェイスの変更はありませんが、JRE 1.2 と 1.3 はサポートされません。この変更の目的は、JDK 1.4 以降だけで利用可能な QoS をサポートすることです。また、jtapi.jar に含まれる Cisco の暗号化ファイルを利用するには JRE 1.3 以降が必要になります。このファイルは TCP を介して CTIManager にパスワードを送信するときに強力なパスワード暗号化アルゴリズムを提供します。JTAPI は、この機能の一部として、パスワードを送信する前に Identity Management System（IMS：Cisco Unified Communications Manager のコンポーネント）が提供する API を呼び出してパスワードを暗号化します。

また、JRE 1.4 を使用することで、JDK 1.4 に追加された新しい API を Cisco Unified JTAPI で利用できるようになります。以前のバージョンの JRE を使用するアプリケーションで Cisco Unified JTAPI を使用するには、JDK 1.4 をインストールする必要があります。

（注）	JTAPI アプリケーションへのインターフェイスに変更はありませんが、JTAPI.jar には RSA jsafe.jar（3.3）ファイルと Apache log4j-1.2.8.jar ファイルが含まれています。これらのバージョンの jsafe.jar（バージョン 3.3）および log4j-1.2.8.jar と互換性がない jar ファイルをアプリケーションで使用している場合、どちらのファイルがクラスパスで先に指定されているかによって、JTAPI またはアプリケーションが正常に動作しないことがあります。

また、この移行により、JTAPIPreferences とサンプル アプリケーションの MS-JVM に対する依存関係も解消されました。[JTAPI の初期設定（JTAPI Preferences）] ダイアログボックスの [詳細設定（Advanced）] タブに次の 2 つの設定パラメータが新しく追加されました。

• JTAPI Post Condition Timeout

• Use Progress As Disconnected

  下位互換性

この機能には下位互換性はありません。

Cisco Unified Communications Manager Administration のリリース 5.0 に接続するために、JTAPI クライアントは Cisco Unified Communications Manager Administration Release 5.0 にバンドルされた新しいバージョンの JTAPI にアップグレードする必要があります。JTAPI のバージョンは 8.5(X.Y)-Z の形式で提供されています。この X、Y、Z は、サブリリースごとに異なります。アプリケーションは、JTAPI の古いリリースと接続できません。

リリース 7.0(1) から、Cisco Unified JTAPI クライアントのインストールで現在サポートされている言語が削除されます。Cisco Unified JTAPI クライアントのインストールでサポートされている言語は英語だけです。また、Cisco Unified Communications Manager サーバから、JTAPI Preference アプリケーションのロケールを動的に更新する機能も追加されます。JTAPI Preference アプリケーションでは、以前のリリースでサポートされていたすべての言語も継続的にサポートされます。新しい言語の追加およびロケール ファイルの更新のサポートも追加されています。

以前のリリースでは、Cisco Unified JTAPI クライアント インストールと JTAPI Preferences アプリケーションはビルド時にローカライズされ、新しい言語のサポートや既存の言語のロケールの更新に対するサポートは追加されていませんでした。JTAPI クライアントのロケールの更新は、Cisco Unified Communications Manager のメンテナンス リリースで実行されていました。ロケール インフラストラクチャの変更により、JTAPI Preferences アプリケーションのロケール ファイルを動的に更新する機能が追加され、JTAPI クライアントのインストールは、英語でだけ実行可能になります。

JTAPI クライアントのインストールには、Cisco Unified Communications Manager TFTP サーバの IP アドレスが必要です。Preferences アプリケーションのロケール ファイルのダウンロードには、TFTP IP アドレスを使用します。TFTP IP アドレスが入力されていない場合や、入力された IP アドレスに誤りがある場合は、Preferences アプリケーションには英語だけが表示されます。今後、新しいロケールの更新が可能になった場合は、JTAPI Preferences アプリケーションから、利用できる更新と最新のロケール ファイルがユーザに通知されます。

管理者はこの機能を使用して、地理的位置を設定し、別の地理的位置の Voice over IP（VoIP）フォンまたは VoIP PSTN ゲートウェイに直接接続された PSTN ゲートウェイを通過するコールを制限できます。この機能により、単一回線のアナログ電話を使用でき、Telecom Regulatory Authority of India（TRAI）規制との互換性を維持できます。

この機能は、Logical Partitioning Enabled サービス パラメータを使用して無効にできます。これはデフォルトで無効にされています。

この機能により、コールごとに、またはメディアが確立されるたびに、IP アドレスおよびポート番号を指定することで、ルート ポイントおよびアプリケーションにあるすべてのアクティブ コールを終端することが可能になります。

この機能を使用するには、メディア機能を提示して、アプリケーションでルート ポイントを登録する必要があります。このルート ポイントでコールが応答されると、アプリケーションに CiscoMediaOpenLogicalChannelEv が送信されます。このイベントは、メディアが確立されるたびに送信されます。アプリケーションはこのイベントに応答し、メディアの終端先となる IP アドレスとポート番号を示す必要があります。

CiscoRouteTerminal は、アプリケーションによる RTP メディア ストリームの終端を可能にする、特殊な CiscoTerminal を表します。CiscoRouteTerminal は、通常の CiscoTerminal と異なり、物理的なテレフォニー エンドポイントではないため、サードパーティ方式で監視、制御することができます。CiscoRouteTerminal は論理的なテレフォニー エンドポイントを表し、コールをルーティングしメディアを終端する必要があるアプリケーションに関連付けることができます。CiscoMediaTerminal とは異なり、CiscoRouteTerminal では複数のアクティブ コールを同時に保持できます。通常、CiscoRouteTerminal は、エージェントが次の発信者に応対できるようになるまでの間、コールをキューに格納するために使用されます。

（注）	JTAPI により CiscoRouteTerminal として表現されるのは、RoutePoint 端末だけです。

メディアの終端プロセスには 3 つの段階があります。

1. アプリケーションが、CiscoRouteTerminal.register メソッドを使用して、メディア機能をこの端末に登録します。

2. CiscoTerminalObserver インターフェイスを実装するオブザーバを、アプリケーションが Terminal.addObserver メソッドを使用して追加します。

3. CiscoRTPHandle を使用してプロバイダーから CiscoCall オブジェクトを受信するために、アプリケーションは、CiscoRouteTerminal または CiscoRouteAddress に addCallObserver を追加する必要があります。

アプリケーションは、コールごとに CiscoMediaOpenLogicalChannelEv を受信するので、CiscoRouteTerminal の setRTPParams メソッドを使用して、IP アドレスおよびポート番号を提示する必要があります。

CiscoJtapiClient 1.4(x) リリース以前で作成されたすべてのアプリケーションは、メディア終端を必要としない場合、修正して CiscoRouteTerminal. NO_MEDIA_TERMINATION に登録する必要があります。

登録されるメディア機能および registrationType が同じであれば、複数のアプリケーションを同じルート ポイントに登録できます。CiscoRouteTerminal.DYNAMIC_MEDIA_REGISTRATION に登録され、端末オブザーバが追加されたすべてのアプリケーションは、CiscoMediaOpenLogicalChannelEv を受信します。ただし、1 つのアプリケーションだけが setRTPParams を呼び出すことができます。

（注）	メディアを終端するアプリケーションは、CallControl パッケージを使用して、コールの応答およびリダイレクトを行う必要があります。コールのルーティングだけを行うアプリケーションは、ルーティング パッケージを使用できます。

（注）	アプリケーションが CiscoMediaOpenLogicalChannelEv に応答する前に何らかの機能が実行された場合、機能が失敗する可能性があることが、アプリケーション側で認識されている必要があります。Cisco Unified Communications Manager Administration ウィンドウにある Media Exchange Timeout パラメータに指定された時間内にアプリケーションがこのイベントに応答しない場合、コールが失敗する可能性があります。

ルート ポイントでのメディア終端用に、次の新しいインターフェイスまたは変更されたインターフェイスがあります

これらのインターフェイスの詳細については、Cisco Unified JTAPI 拡張を参照してください。ルート ポイントでのメディア終端のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

メディア終端機能を利用すると、オーディオやビデオなどのコールのベアラの、アプリケーションによる送信およびキャプチャができます。このアクションは、メディアの「再生と録音」または「ソースとシンク」と表現されることもあります。" "" "メディア終端は、コールのセットアップやティアダウンの詳細ではなく、コールのエンドポイント間を流れるデータに関与するため、コール制御とは区別されます。たとえば、自動着信呼分配（ACD）では、コール制御を使用して使用可能なエージェント間でコールがルーティングされますが、メディアは終端されません。その一方で、音声自動応答装置（IVR）アプリケーションでは、コール制御を使用してコールの応答または接続解除を行い、メディア終端を使用して発信者側に対してサウンド ファイルを再生します。

メディア終端に単独で関与するテレフォニー アプリケーションはありませんが、この機能は常にコール制御と組み合わせて使用されます。JTAPI 1.2 では、主にコール制御仕様が記述されており、メディア終端を必要とするアプリケーションには非常に限定的なサポートしか提供されません。Cisco Unified Communications ソリューションのプラットフォームでは、JTAPI 標準よりも高度なメディア終端がサポートされるため、Cisco Unified JTAPI 実装では、JTAPI を拡張してこの機能のフル サポートを追加しています。

Cisco Unified JTAPI では、Computer Telephony Integration（CTI）ポートを使用して、ソフトウェアベースのメディア終端が行われます。これらのポートには、コールの発信または受信に使用可能な 1 本以上の回線（ダイヤル可能な番号）があります。ただし、これらのポートにはメディアのソースとシンクを提供する制御アプリケーションが必要です。アプリケーションは、Cisco Unified Communications Manager を使用して、メディア終端ポートへの関与を登録します。これで、Cisco Unified Communications Manager からアプリケーションにこの仮想デバイスに関連するすべてのイベントが配送されます。Cisco Unified JTAPI では、CTI ポートは CiscoMediaTerminal と表現されます。次の図に CTI ポートの構成を示します。CTI ポートの管理と構成についての詳細は、Cisco Unified Communications Manager Administration の情報を参照してください。

ソフトフォン アプリケーション（たとえば、PC が電話機として動作）を実装する場合は、Cisco Unified JTAPI アプリケーションを使用して CTI ポートを管理します。

メッセージ待機インジケータ（MWI）機能の拡張により、アプリケーションは、拡張メッセージ受信カウントをサポートする電話に次のメッセージ カウントを表示することができます。

• 新しい音声メッセージ（標準および高い優先度を含む）の合計件数

• 以前の音声メッセージ（標準および高い優先度を含む）の合計件数

• 高い優先度の新しい音声メッセージの件数

• 高い優先度の以前の音声メッセージの件数

• 新しい FAX メッセージ（標準および高い優先度を含む）の合計件数

• 古い FAX メッセージ（標準および高い優先度を含む）の合計件数

• 高い優先度の新しい FAX メッセージの件数

• 高い優先度の以前の FAX メッセージの件数

拡張 MWI メッセージ概要を提供するために、CiscoAddress JTAPI 拡張として、2 つの新しい API が追加されています。既存の setMessageWaiting API と同様に、一方の API では、監視対象のアドレスに対して概要を設定できます。他方の API では、監視対象のアドレスの設定済みのコーリング サーチ スペースに定義されている、監視対象のアドレスで到達可能な任意のアドレスにメッセージ概要を設定することができます。

これらの新しい API は拡張メッセージ カウントをサポートしない電話タイプで使用することもできます。これらの API をサポートされない電話で使用した場合、既存の setMessageWaiting メソッドと同じように動作します。つまり、メッセージ受信インジケータ ランプが点灯または消灯するだけで、カウントは表示されません。

この機能は、ルート ポイントから SelectRoute API の発信者 DN を変更することを可能にします。アプリケーションは、selectRoute API で発信側番号変更の配列を渡すことができます。発信側番号変更の配列の長さは、選択されたルートの長さと等しくすることができます。対応する routeSelected インデックスに発信側番号変更の要素がない場合、または要素が null である場合、このルート選択要素には発信者番号変更が設定されません。

2 種類の新しいインターフェイスである getModifiedCallingAddress () と getModifiedCalledAddress () が、発信者または着信者の変更された番号を返すコール オブジェクトに公開されます。変更がない場合、これらのインターフェイスは、getCurrentCallingAddress () インターフェイスおよび getCurrentCalledAddress () インターフェイスと同じ値を返す可能性があります。アプリケーションは、selectRoute API を使用してルート ポイントの制御と発信者番号の変更を行っているだけである場合、getModifiedCallingAddress インターフェイスの発信者アドレス変更を取得できない可能性があります。アプリケーションは、いずれかの発信者または着信者を制御している場合、発信者番号の変更後にコール制御イベントを受信すれば、正しい値を取得できます。

新たに getRouteSelectedIndex () インターフェイスが、新しい CiscoRouteUsedEvent クラスで公開されました。このクラスは、RouteUsedEvent の拡張で、選択されたルートのインデックスを提供します。このメソッドにアクセスするには、アプリケーションは RouteUsedEvent から CiscoRouteUsedEvent へキャストする必要があります。

routeSelected[0]  =  133555 
routeSelected[1]  =  144911 
routeSelected[2]  =  143911 
routeSelected[3]  =  5005  

modifiedCallingNumber[0]  = null
modifiedCallingNumber[1]  = 9721234567
modifiedCallingNumber[2]  = 9721234568
modifiedCallingNumber[3]  = null

ルーティングで routeSelected[0] または routeSelected[3] が選択された場合、発信者番号の変更が適用されない可能性があります。

この機能は、特定のユーザの Cisco Unified Communications Manager Administration にある、発呼側番号の変更を可能にするチェックボックス（デフォルトでは [False]）を管理者が有効にした後にのみ使用できます。これが設定されていない場合、RouteSession.CAUSE_PARAMETER_NOT_SUPPORTED という原因の RerouteEvent がアプリケーションに送信されます。発信者番号を変更するアプリケーションでは、着信者の表示名が影響されることと、それに続く発信者または着信者の機能の対話に不整合が生じる場合があることに注意する必要があります。

発信者番号の変更には、次の新しいインターフェイスまたは変更されたインターフェイスがあります。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。発信者番号の変更のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

Cisco Unified Communications Manager では、Multilevel Precedence and Preemption（MLPP）用に設定された電話機による補足サービスの使用ができます。Cisco Unified Communications Manager は、コールにアプリケーションの優先順位レベルを維持することで実現します。

（注）	JTAPI では、アプリケーションの優先順位レベルを提供していません。

DN あたりの複数コールは、1 回線（DN）上での複数コールと、これらのコール機能の操作をサポートする機能を表します。Cisco Unified Communications Manager Release 4.0(1) よりも前では、最大 2 つのコールしかサポートされていませんでした。Cisco JTAPI は、1 回線あたり複数のコールをサポートします。これにより、同一回線上で複数のコールを扱い、この回線上で機能を操作することが可能になります。

DN あたりの複数コールによる、インターフェイスやメッセージ フローの変更はありません。

コール分配機能を使用して、ハント メンバで同時に処理できる数よりも多くのコールをハント パイロットに分配することは、Cisco Unified CM の配置ではよくあることです。ネイティブ キューイング機能は、コールが応答されるまでそのコールをキューに保持します。ハント メンバが使用可能になると、コールがキューから削除されて、ハント メンバに提供されます。

この機能を有効にするには、Cisco Unified CM 管理者が [ハントパイロットの設定（Hunt Pilot Configuration）] ページの [キューイング（Queuing）] セクションで、[コールをキューイング（Queue Calls）] チェックボックスを有効にする必要があります。ネイティブ キューイングの機能設定では、次のように設定できます。

• [キューで許可されている最大発信者数（1 ～ 100）（Maximum Number of Callers Allowed in Queue (1–100)）]：キュー項目数の設定で、同時にキュー内に存在できる最大コール数を示します。

  • [キューが最大数に達した場合の接続先（Destination When Queue is Full）]：キュー制限で許可されている最大発信者数に達したときにコールが転送される先の、ユーザ設定可能な接続先番号。

  • [切断（Disconnect）]：このオプションの結果として、キュー制限で許可されている発信者が最大数に達した場合、コールは拒否およびドロップされます。

• [キュー内の最大待機時間（10 ～ 3600 秒）（Maximum Wait Time in Queue (10–3600 seconds)）]：コールがキュー内に存在できる、ユーザ設定可能な最大待機時間。

  • [最大待機時間に達した場合の接続先（Destination When Maximum Wait Time is met）]：キューの最大待機時間に達したときにコールが転送される先の、ユーザ設定可能な宛先 DN。

  • [切断（Disconnect）]：このオプションの結果として、キューの最大待機時間に達した場合、コールは拒否およびドロップされます。

• [ログイン中または登録済みのハント メンバが存在しない場合（When There Are No Hunt Members Logged In or Registered）]：ハント パイロットのハント メンバがどれも登録されていないかログインしていない場合に、キュー機能がコールを転送する先の、ユーザ設定可能な宛先 DN。

  • [切断（Disconnect）]：このオプションの結果として、ダイヤルされたハント パイロットに使用可能なハント メンバが存在しない場合、コールは拒否およびドロップされます。

  • [接続先（Destination）]：ダイヤルされたハント パイロットに使用可能なハント メンバが存在しないときにコールが転送される先の、ユーザ設定可能な宛先 DN。

すべてのメンバがビジー状態であるハント パイロットに発信側がコールを発信すると、CiscoHuntConnection が一時的に作成されます。そのため、この機能が有効な場合、ハントの接続はドロップされ、ハント パイロットのアドレス名と同じアドレス名を持ち、アドレス タイプが CiscoAddress.INTERNAL である新しい接続が作成されます。この新しい接続が CallControlConnection.QUEUED 状態ステートに移行し、コールがキュー解除されるかドロップされるまでその状態を維持します。

Cisco JTAPI では、次の新しい理由を公開しています。

• CiscoFeatureReason.REASON_QUEUING

• CiscoFeatureReason.REASON_DEQUEUING

• CiscoFeatureReason.REASON_DEQUEUING_TIMER_EXPIRED

• CiscoFeatureReason.REASON_DEQUEUING_AGENTS_BUSY

• CiscoFeatureReason.REASON_DEQUEUING_AGENTS_UNAVAILABLE

ハント パイロットにはさまざまな設定があるため、上記の理由でコールがそれぞれいつキューに入り、いつキュー解除されたかを示します。

（注）

キューイングされているコールと会議する場合は、動作が異なります。キューに入っている発信側が別の参加者と電話会議を行うと、キューイングされている接続はドロップされ、ハント パイロット番号のアドレスを使用した新しい接続が作成されて、アドレスタイプは CiscoAddress.UNKNOWN になり、CallControlConnection.ESTABLISHED 状態に移行します。 たとえばエージェントがフリー状態になってコールがキューから削除されると、エージェントが会議に追加され、そのための接続が作成されます。ハント パイロットの場合、JTAPI は CiscoHuntConnection ではなく、通常の接続を作成します。これは、ハント パイロットとの会議を処理する際の JTAPI の制限です。 ハント メンバのみが監視される場合は、何も問題なく、JTAPI でそれを処理できます。

以前のリリースの Cisco JTAPI（Cisco JTAPI バージョン 1.4(x.y)）では、クラスタ外のアドレスへのコールを開始すると、遠端のアドレスに CallCtlConnNetworkReachedEv イベントと CallCtlConnNetworkAlertingEv イベントが配信されていました。

最近のバージョンの Cisco Unified Communications Manager（4.0 以降）および Cisco Unified JTAPI（2.0）では、これらのイベントは配信されていません。これらのバージョンでは、遠端アドレスの CallCtlConnection が OFFERED 状態から ESTABLISHED 状態に移行しました。以前のバージョンの Cisco Unified JTAPI では、"オーバーラップ送信"がオフの状態でゲートウェイ経由のコールが発信されたときに、遠端アドレスに対して CallCtlConnOfferedEv および CallCtlConnEstablishedEv が配信されていました。CallCtlConnNetworkReachedEv および CallCtlConnNetworkAlertingEv イベントはアプリケーションに配信されませんでした。

Cisco Unified Communications Manager 4.0 および 4.1 では、ネットワーク イベントを受信するために、ゲートウェイに対して設定されているルート パターンの [オーバーラップ送信を許可（Allow Overlap Sending）]" "フラグ、または jtapi.ini の "AllowNetworkEventsAfterOffered" パラメータをオンにする必要がありました。

Cisco Unified Communications Manager リリース 5.0 では、[オーバーラップ送信を許可（Allow Overlap Sending）]" "フラグが有効な場合、ゲートウェイの向こう側にある遠端アドレスの ConnCreatedEv、CallCtlConnNetworkReachedEv、CallCtlConnNetworkAlertingEv、および CallCtlConnEstablishedEv がアプリケーションに配信されます。

[オーバーラップ送信を許可（Allow Overlap Sending）]" "フラグが有効でない場合は、ゲートウェイの向こう側にある遠端アドレスの ConnCreatedEv、CallCtlConnOfferedEv、CallCtlConnNetworkReachedEv、CallCtlConnNetworkAlertingEv、および CallCtlConnEstablishedEv がアプリケーションに配信されます。

（注）	AllowNetworkEventsAfterOffered は、Cisco Unified Communications Manager Release 5.0 では使用できません。上記のイベントは jtapi.ini のパラメータ設定に関係なく配信されます。

このイベントは、TerminalRegistration が何らかの理由で失敗したときに、アプリケーションに送信されます。getErrorCode() インターフェイスの戻り値で、障害の種類が示されます。このイベントを受け取った場合、アプリケーションは Terminal の再登録を試みる必要があります。このバージョンでは、新しい戻り値がこのインターフェイスに追加されました。不明な障害を処理するために、CiscoTermRegistraionFailedEv.UNKNOWN が、このバージョンから導入されました。

会議に参加しているすべての通話者が、会議に参加者を追加できるようになりました。以前のリリースでは、参加者を追加できるのは会議コントローラだけでした。

• CiscoConferenceStartEv には、要求者の識別子が含まれています。

• メソッド getConferenceControllerAddress は、要求者の TerminalConnection を返します。

• CiscoConferenceStartEv の新しいメソッド getOriginalConferenceControllerAddress() は、元のコントローラの TerminalConnection 接続を返します。

Cisco Unified JTAPI アプリケーションは、コールがパークまたはパーク解除されたときにイベントを受信するように登録できます。この機能に登録すると、プロバイダー オブザーバに CiscoProvCallParkEv イベントが配信されます。この機能に正常に登録するには、ユーザの「コール" "パーク取得の許可」フラグがオンになっている必要があります。Cisco Unified Communications Manager Administration のユーザ設定からこのフラグにアクセスできます。この機能に登録すると、クラスタ内のデバイスでコールがパークまたはパーク解除されるたびに、アプリケーションが CiscoProvCallParkEv イベントを受信します。

この機能の登録および登録解除は、次の新しいインターフェイスで行えます。

public interface CiscoProvider { public void registerFeature ( int featureID ) throws InvalidStateException, PrivilegeViolationException; public void unregisterFeature ( int featureID ) throws InvalidStateException; }

featureID は CiscoProvFeatureID.MONITOR_CALLPARK_DN です。

この機能は、パーク要求を呼び出すアプリケーションに、パークの復帰動作を提供します。現在、パークの復帰タイマーが切れると、コールがパーク元のアドレスに戻されます。新しい動作によって、パーク モニタリング復帰タイマーが切れても、コールはパーク DN にパークされたままになります。

この機能により、パーク元のアドレスでパークされているコールのステータス モニタリングも可能になります。新しい電話（6900 シリーズ以降）で既存の CiscoConnection.park() JTAPI API を使用するか、電話自体から直接、コールをパークすると、Cisco Unified JTAPI はパークされているコールの現在のステータスを含む新しいイベント CiscoAddrParkStatusEv を配信します。アプリケーションはパーク元のアドレスに AddressObserver を追加し、このイベントを受け取るフィルタを有効にする必要があります。コールがパークされた後にアプリケーションがオブザーバを追加した場合、CAUSE_SNAPSHOT でイベントが配信されます。新しいイベントのパーク ステータスは次のいずれかである可能性があります。

• Parked：アプリケーションのユーザによってコールがパークされたことを示します。

• Reminder：パークされているコールのパーク モニタリング復帰タイマーが切れたことを示します。

• Retrieved：以前にパークされたコールが取得されたことを示します。

• Abandoned：以前にパークされたコールが取得を待つ間に切断されたことを示します。

• Forwarded：Park Monitoring Forward-No-retrieve タイマーが切れたときに、パークされているコールが設定されている Forwarded No Retrieve Destination に転送されたことを示します。

原因が CAUSE_SNAPSHOT の場合、パーク ステータスは、Parked または Reminder 状態のいずれかになります。

電話では、これらの通知が対象となります。つまり、コールをパークしているデバイスだけがこれらの通知を認識できます（パーク元のデバイスと回線を共有する他のデバイスは同様の通知は受け取りません）。Cisco Unified JTAPI に、これを管理するための CiscoAddrParkStatusEv の getTerminal() インターフェイスが追加されています。このインターフェイスは、これらの通知を受け取ったアドレスの端末を返し、この端末はコールをパークした端末です。

さらに、Cisco Unified JTAPI はこの新しいイベントで、アプリケーションに CiscoCallID も提供します。アプリケーションはこれを使用して、コール オブジェクトを取得できます。ただし、このイベントを受け取った時点で、プロバイダーのドメインにコールが存在しない場合、CiscoCallID.getCall() は Null 値を返すことがあります。

Cisco Unified JTAPI は、アプリケーションへの新しいイベント通知を制御またはフィルタする新しいインターフェイス CiscoAddrEvFilter を提供しています。アプリケーションは、CiscoAddrEvFilter インターフェイスの API getCiscoAddrParkStatusEvFilter() および setCiscoAddrParkStatusEvFilter() によってフィルタ値を取得または設定できます。CiscoAddrEvFilter インターフェイスでフィルタの値を取得し、設定するための 2 つの新しいメソッド getFilter() と setFilter() も CiscoAddress に提供されています。フィルタが有効にされており、CiscoAddress で setFilter() が呼び出されている場合に限り、アプリケーションは新しいイベント通知 CiscoAddrParkStatusEv を受け取ります。下位互換性を維持するために、デフォルトで、CiscoAddrParkStatusEvFilter のフィルタ値は False にされています。

コールがパークされると、パーク モニタリング復帰タイマーが開始し、期限が切れると Reminder が送られ、この後、Park Monitoring Forward No Retrieve タイマーが開始します。このタイマーが切れ、未取得時のパーク モニタリング転送の接続先が設定されている場合、コールがその宛先に転送されます。転送先で Connection が作成されると、Connection イベントで新しい CiscoFeatureReason FORWARD_NO_RETRIEVE が配信されます。未取得時のパーク モニタリング転送の接続先が設定されていない場合、パークの復帰が発生した場合と同じ理由（CiscoFeatureReason.PARKREMINDER）で、パークコールが元の DN に返送されます。

アプリケーションが CiscoAddress.getAddressCallInfo(Terminal term) を呼び出したときに、返される CiscAddressCallInfo が拡張され、パークされているコール数が含まれるようになりました。これはパークされているコール数を返します。Cisco Unified IP Phone 7900 シリーズ（SIP/SCCP）は、このアドレスによってパークされたコールがある場合でも 0 の値を返します。

この機能は、新しい電話（6900 シリーズ以降）でコールがパークされている場合に限り適用します。Cisco Unified IP Phone 7900 シリーズ（SIP/SCCP）でコールがパークされた場合、引き続き既存の動作が行われます。新しい Cisco Unified IP Phone でコールをパークし、Cisco Unified IP Phone 7900 シリーズ（SIP）と回線を共有している場合、新しいパーク モニタリング拡張が機能します。ただし、Cisco Unified IP Phone 7900 シリーズ（SIP または SCCP）でパークした場合、アプリケーションがこれらの回線をモニタしている場合でも、すべての電話で古いパーク動作が行われます。

ユーザは必要に応じて、パーク モニタリング復帰タイマーを 0 に設定し、Park Monitoring Forward No Retrieve タイマーを既存の Park Reversion Duration タイマーに設定して、新しい Cisco Unified IP Phone（未取得時のパーク モニタリング転送の接続先が設定されていない場合）で古い動作を得ることができます。ただし、イベント通知は制御できません。

Cisco Unified Communications Manager サービス パラメータ ページで、先述のタイマーを設定できます。これらは、Cisco Unified IP Phone の将来のモデルの SIP バージョンだけに適用されます。

パーク モニタリング復帰タイマー：このタイマーはコールがパークされるとただちに開始します。これは、ユーザにパークされているコールがあることを通知するまでのコールがパークされている時間です。この範囲は 0 ～ 1200 秒で、デフォルト値は 60 秒です。

Park Monitoring Periodic Reversion タイマー：ユーザがパークされているコールについて通知される頻度。この範囲は 0 ～ 1200 秒で、デフォルト値は 30 秒です。

Park Monitoring Forward No Retrieve タイマー：このタイマーはパーク モニタリング復帰タイマーが期限切れになると開始します。これは、パーク先がパーク元の未取得時のパーク モニタリング転送（FNR）の宛先にリダイレクトされるまでのパーク リマインダ通知が再生される秒数です。この範囲は 30 ～ 1200 秒で、デフォルト値は 300 秒です。

未取得時のパーク モニタリング転送の接続先は、Cisco Unified Communications Manager 回線ページ設定の回線ページで設定できます。

Assisted DPark は、電話で DPark 操作を実行するための代替の 1 手順の方法を提供します。ユーザが新しい電話（6900 シリーズ以降）から Assisted DPark を実行し、アプリケーションがパークされている相手をモニタしている場合に、Cisco Unified JTAPI は DPark DN の接続イベント（ConnCreatedEv、ConnInProgressEv、および CallCtlConnQueuedEv）に理由 CiscoFeatureReason.REASON_REFER を提供します。従来の DPark が実行されると、アプリケーションは CiscoFeatureReason.REASON_TRANSFER の接続イベントを受け取ります。

パークされたコールが指定時間内に取得されないと、コールのパークされたアドレスにリマインダ コールが返され、パーク番号 Connection は Disconnected 状態に移行します。コールは再接続され、確立された状態に移行します。コールのパークされたアドレスに Talking 状態の TerminalConnection が作成されます。

コールが IP フォンからパークされると、電話機にパーク番号が表示されます。どの端末からでも、パーク番号をダイヤルすればコールのパークを解除できます。コールのパークが解除されると、パークを解除したアドレスに接続する新しいコールが作成されます。Queued 状態にある元のコールのパーク番号に対する CallControlConnection は、Disconnected 状態に移行します。

Cisco Unified Communications Manager リリース 5.0 よりも前では、JTAPI はパーティションをサポートしていませんでした。JTAPI では、DN が同じでパーティションが異なるアドレスが、同じアドレスと見なされていました。このような場合、アドレスが DN だけによって識別され、パーティション情報によって識別されないため、Address オブジェクトが 1 つしか作成されませんでした。

リリース 5.0 からは、同じ DN を持ちながら異なるパーティションに属するアドレスが JTAPI でサポートされ、それぞれを異なるアドレスとして扱うことが可能になりました。アドレスのパーティション情報は、後述のメソッドを通じてアプリケーションに公開されます。アプリケーションでこのパーティション サポート機能を利用するには、JTAPI インターフェイスを通じて提供される API と、それに応じたアドレス オブジェクトを使用する必要があります。

この機能は下位互換性があります。JTAPI は、アドレス オブジェクトのオープンとアクセスに現在使用されている API をサポートしています。

Cisco Unified Communications Manager リリース 5.0 では、JTAPI がパーティションに対応しており、次の構成がサポートされています。

• パーティションが同じで、デバイスが異なる同一 DN のアドレスは、共用回線として扱われます。

• 同じパーティションと同じデバイス内の同一 DN のアドレスは使用できません。

• パーティションが異なり、同じデバイスにある同一 DN のアドレスは、異なるアドレスとして扱われます。この場合は 2 つのアドレス オブジェクトが作成され、アプリケーションではアドレス オブジェクトの getPartition() API を呼び出すことによってこれら 2 つを区別できます。

• パーティションが異なり、デバイスが異なる同一 DN のアドレスは、異なるアドレスとして扱われます。この場合は 2 つのアドレス オブジェクトが作成され、アプリケーションではアドレス オブジェクトの getPartition() API を呼び出すことによってこれら 2 つを区別できます。

JTAPI でのパーティション サポートに関する変更は、アドレス オブジェクトに限定されており、JTAPI の他の関数やクラスには影響はありません。次のセクションではインターフェイスの変更点について説明します。

CiscoAddress インターフェイス

このクラスでは、次のシグニチャを持つ新しいメソッドが提供されています。

string getPartition ()

アドレス オブジェクトのパーティション文字列を返します。アプリケーションがパーティション情報を取得するにはこのメソッドを使用する必要があります。JTAPI ではこのパーティション情報を使用して、DN が同じでパーティションが異なるアドレスを区別し、特定のアドレスを開くためのパーティション情報を送信します。

たとえば、プロバイダーのオープンで A(1000, P1) および B(1000, P2) という 2 つのアドレスが返されたとします。A と B はアドレス オブジェクトを、1000 はアドレス オブジェクトの DN を、P1 と P2 はアドレスが属するパーティションをそれぞれ表します。

ユーザが A.getPartition () を呼び出すと P1 が返され、B.getPartition () を呼び出すと P2 が返されます。

provider.getAddresses() メソッドは、DN が同じでパーティション情報が異なる Address オブジェクトの場合に、複数のアドレスを返します。アプリケーションでこのメソッドを使用することで、DN が同じで異なるパーティションに属する 2 つの Address オブジェクトを区別できます。

CiscoProvider インターフェイス

CiscoProvider インターフェイスでは次のメソッドが提供されています。

Address[]	getAddress(String number) 各パーティションの number に対応する Address オブジェクトの配列を返します。
Address	getAddress(String number, String partition) number パラメータと同じ DN を持ち、partition パラメータで指定されているのと同じパーティションに属する Address オブジェクトを返します。

A(1000, P1) および B(1000, P2) という 2 つのアドレスがあるとします。A と B はアドレス オブジェクトで、1000 は 2 つのアドレス オブジェクトの DN を表しており（どちらも同じ値になっています）、P1 および P2 は各アドレスが属するパーティションを示します。アプリケーションが provider.getAddress("1000") を呼び出すと、A および B という 2 つのアドレス オブジェクトが取得されます。

アプリケーションで A.getPartition() を呼び出すと P1 が返され、B.getPartition() を呼び出すと P2 が返され、以降、同様です。アプリケーションでは getPartition メソッドを使用して、2 つのアドレス オブジェクトを区別できます。

アプリケーションで provider.getAddress(1000, P1) を呼び出した場合を考えます。この場合、アプリケーションでは、DN が 1000 でパーティションが P1 のアドレス オブジェクトを探します。この場合は、プロバイダー オブジェクトによって「A」が返されます。" "

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。パーティションのサポートに関するメッセージ シーケンスを確認するには、メッセージ シーケンスの図を参照してください。

管理者は、CUCM 管理パネルを使用して、ログイン クレデンシャルのオプションを設定できます。パスワード有効期限切れの設定では、管理者は次の 2 つのパラメータを指定できます。

1. パスワードの有効期限が切れるまでの時間（日数）および

2. ユーザにパスワードを変更するように警告する、パスワードの有効期限が切れる前の日数。

パスワードの有効期限が切れると、JTAPI はアプリケーションに例外を配信します。パスワードの有効期限がもうすぐ切れる場合、JTAPI は新しいイベントをアプリケーションに配信します。アプリケーションでこれらの値を変更することはできません。JTAPI は情報を報告するだけです。

永続的接続は、Unified Communications Manager Release 9.1 で実装された Cisco Extend and Connect 機能の拡張です。永続的コールとは、Unified Communications Manager（CTI リモート デバイス）とリモート接続先との間のコールで、コールのドロップ後も有効状態のままであるコールを指します。JTAPI API とエラー コードが追加されました。

JTAPI は、新しい API である CiscoAddress.createPersistentCall() をサポートします。これにより、アプリケーションは永続的コールを作成できます。少なくとも 1 個のリモート接続先が設定され、アクティブなリモート接続先が指定されている必要があります。永続的コールは、リモート デバイスごとに 1 つだけ作成できます。永続的コールは、すでにリモート デバイスにコールがある場合は作成できません。作成すると、アプリケーションは CiscoJtapiException.OPERATION_NOT_AVAILABLE_IN_CURRENT_STATE を受信します。さらに、永続的コールでの機能呼び出しと、永続的コールを使用する機能呼び出しは、いずれも許可されません（パーク、保留、会議、転送）。

2 つの新しい JTAPI API が、永続的コールについての情報を返します。CiscoAddress.getPersistentConnection() API は、永続的コールに関連付けられた connection オブジェクトを返します。永続的コールが存在しない場合は null が返されます。また、この API は、アドレスに永続的接続が作成されているかを確認し、そこからコール オブジェクトを取得することもできます。新しく追加された、もう 1 つの API は、CiscoCall.isPersistentCall() で、コールが永続的コールの場合は true、通常のコールの場合は false を返します。

Provider.getCalls()、Address.getConnections()、Terminal.getTerminalConnections() などの既存の JTAPI API は、通常のコールの情報のみを返し、永続的コールについては何も返しません。Provider.getCalls() は、プロバイダーに関連付けられたすべてのコールを返しますが、永続的コールは返しません。Address.getConnections() はそのアドレスに関連付けられたすべての Connection オブジェクトを返しますが、永続的コールの Connection は返しません。Terminal.getTerminalConnections() はそのアドレスに関連付けられたすべての Terminal Connection オブジェクトを返しますが、永続的コールの Terminal Connection は返しません。この機能には下位互換性があるため、アプリケーションの現在の実装に変更を加える必要はありません。

永続的コールを切断するための新しい API は追加されていません。既存の Call.drop() および Connection.disconnect() JTAPI API を使用して、永続的コールを切断したり、ドロップしたりできます。永続的コールは、リモート デバイスへのアクティブ コールがある場合はドロップできません。永続的コールは、次のシナリオのいずれかでもドロップされます。

• コールがリモート接続先によってドロップされる（リモート接続先が切断される）。

• リモート接続先がアクティブでなくなる。アクティブ コールがある場合は、そのコールが終了するとすぐに、永続的コールがドロップされます。

永続的コールは、作成されると、コールがクリアされる最大コール長タイマーが期限切れになるまで、接続されたままになります。

この機能の一部として導入された新しい JTAPI エラー コードには、次のようなものがあります。

• CiscoJtapiException.CTIERR_CREATE_PERSISTENT_CALL_FAILED：永続的コール作成に問題が発生したことを示します。
• CiscoJtapiException.CTIERR_PERSISTENT_CALL_EXISTS：永続的コールがすでに存在することを示します。
• CiscoJtapiException.CTIERR_OPERATION_NOT_ALLOWED_ON_PERSISTENT_CALL：指定した動作が永続的コールでは許可されていないことを示します。
• CiscoJtapiException.CTIERR_DISCONNECT_PERSISTENT_CALL_FAILED_CALL_ACTIVE：アクティブなカスタマー コールがあるために、永続的コールの切断要求が失敗したことを示します。永続的コールを切断できるのは、アクティブ コールがないときだけです。
• CiscoJtapiException.CTIERR_PERSISTENT_CALL_BEING_SETUP：永続的コールはすでにセットアップ中のため、要求が失敗したことを示します。

zip トーン再生機能により、Cisco JTAPI アプリケーションはアクティブなコールで zip トーンを再生することができます。アプリケーションは、トーンのタイプと方向を指定します。

zip トーンはコールのローカル エンドまたはリモート エンドで再生されます。また、IP 電話機でのみ聞こえて再生されます。リモート サイドがトランク、会議、または Cisco Media Terminal や Route Terminal の場合、zip トーンは再生されません。

次のトーンは再生されます。

• CiscoTone.ZIPZIP

• CiscoTone.ZIP

• CiscoTone.CALLWAITINGTONE

コード例

Void playTone(TerminalConnection termConn, int tone, int direction){ If ( termConn ! = null ){ try { ((CiscoTerminalConnection)termConn).playTone(tone, direction); } catch (Exception e){ System.out.println("Exception for playtone request " + e); }

コールのプレゼンテーション インジケータ（PI）は、エンド ユーザに対して Calling/Called/CurrentCalling/CurrentCalled/LastRedirecting の名前および番号を隠したり見せたりする機能をアプリケーションに提供します。JTAPI には、通話者の PI 値を取得する CiscoCall の関数があります。この PI 情報を使用して、通話者の情報をエンド ユーザに提示します。これらの関数は、true または false の値を返します。値「True」は「許可（Allowed）」のプレゼンテーション、値「False」は「非許可（Restricted）」のプレゼンテーションを示します。" "" "" "" "

会議通話では、CiscoCall のこのインターフェイスは正しい値を返しません。アプリケーションは、コール内のすべての Connection を繰り返して確認し、Connection の作成先アドレスに関連付けられた PI 値を取得する必要があります。CiscoConnection で提供されるインターフェイスは、getAddressPI( ) です。

CiscoCall の次の新しいインターフェイスは PI 値を取得します。

CiscoConnection の次のインターフェイスは、Connection に関連付けられたアドレスの PI 値を取得します。

メッセージ フローの変更はありません。

この機能は、保留中のプライベート コールのプライバシーを強化するものです。プライバシーが有効になっていると、コールを保留状態にした電話機だけがそのコールを取得でき、発信者の名前と番号は表示されません。

この機能では、共用アドレスで、他の共用アドレスからのコールへの割り込みを許可するかどうかを決定することができます。プライバシーを有効にすると、他の共用アドレスからコールに割り込めなくなります。プライバシーは、端末のプロパティです。IP フォンでは、プライバシー機能ボタンによって、ユーザがプライバシー機能の有効と無効を切り替えることができます。端末のアクティブ コールに対しては、プライバシーの有効と無効を動的に切り替えることができます。コールのプライバシーがオンになっているときには、他の共用アドレスから参照できる TerminalConnection の状態は In Use（使用中）に設定されます。CallProgress 中にプライバシーの状態が変化した場合は、CiscoTermConnPrivacyChangedEvent がアプリケーションに配信されます。

以前のリリースでは、プライバシーが有効の場合にコールが保留状態にされると、すべての TerminalConnection が TermConnHeld 状態になり、他の共用アドレスの任意の terminalConnection からコールの保留を解除できていました。Cisco Unified Communications Manager 4.2 では、Enforce Privacy on Held Calls サービス パラメータが有効になっている場合に、コールのプライバシーが有効になっていると、コールを保留状態にしても他の共有アドレスの terminalConnection は変更されず、In Use（使用中）状態のままになります。

欧州の PSTN で、API を通じて未割り当ての電話番号にコールが発信された場合、アプリケーションは、原因コードが CiscoCallEv.CAUSE_UNALLOCATEDNUMBER に設定された ConnFailedEv イベントを受信します。米国の PSTN の場合は、まったくイベントを受信しないことがあります。

欧州の PSTN を経由した場合と米国の PSTN を経由した場合の動作を一貫性のあるものとし、同時に下位互換性の問題にも対処するために、UseProgressAsDisconnectedDuringErrorEnabled という新しいサービス パラメータが JTAPI バージョン 1.4(3.21) で jtapi.ini ファイルに追加されています。このパラメータを有効（1 = 有効、0 = 無効、デフォルトは無効）にすると、両方の場合にアプリケーションが ConnFailedEv を受信します。

QSIG パス交換は、QSIG トランクを介して接続されている PBX 間でコールが転送されるときに、リアルタイム プロトコル（RTP）パスを最適化するネットワーク機能です。パス交換の実行中は、アプリケーションからの機能要求が無視されて JTAPI からアプリケーションに例外がスローされる短い期間が発生します。

RTP パスが始端および終端の PBX をつなぐダイレクト パスに最適化されると、コールの Global Call ID が変更されます。JTAPI には、このコールをモニタリングするための新しいインターフェイスが用意されています。

QuietClear は、Cisco Unified Communications Manager の停止、CTIPort を制御しているアプリケーションの停止、または CTIManager の停止などのネットワーク障害が原因で、コールの 2 つの通話者のうち、一方のアドレスがアウト オブ サービスになると、もう一方の端に示されます。この段階では、コールのもう一方の端では、コールの破棄または接続の解除だけができます。他の callControl 操作は実行できません。

アウト オブ サービスになった通話者については、アプリケーションには ConnDisconnectedEv や TermConnDroppedEv が送られ、コールのもう一方の端では、ConnFailedEv と CiscoCallEv.CAUSE_TEMPORARYFAILURE の CiscoCause が受信されます。

QuietClear モード時にアプリケーションによって次の機能の起動が試みられると、CiscoJtapiException.CTIERR_OPERATION_FAILER_QUIETCLEAR のエラー コードとともに PlatformException がスローされます。

• コンサルト転送

• コンサルト会議

• ブラインド転送

• 保留

• 保留解除

（注）	アプリケーションは、このモードではコールの破棄だけができます。

2 つのエンドポイント間にメディア ストリームが作成される場合は必ず、Cisco Unified Communications Manager から双方のエンドポイントに送信開始と受信開始のイベントが発行されます。JTAPI では、CiscoRTPOutputStartedEv イベントと CiscoRTPInputStartedEv イベントで送信開始と受信開始のイベントを表します。CiscoRTPOutputStartedEv.getRTPOutputProperties() メソッドでは CiscoRTPOutputProperties オブジェクトが返されます。アプリケーションでは、このオブジェクトから、コールのピア エンドポイントの送信先アドレス、およびペイロード タイプやパケット サイズなどのストリームに関する RTP プロパティを確認できます。同様に、CiscoRTPInputStartedEv.getRTPInputProperties() メソッドでは、アプリケーションに着信ストリームの RTP 特性を通知する CiscoRTPInputProperties オブジェクトが返されます。

メディアが流れている間は常に、CiscoMediaTerminal.getRTPOutputProperties() メソッドと CiscoMediaTerminal.getRTPInputProperties() メソッドから現在の CiscoRTPOutputProperties と CiscoRTPInputProperties も使用できます。CiscoMediaTerminal でメディアの送受信が想定されていない場合、これらのメソッドによって例外がスローされます。

Cisco Unified Communications Manager によって、たとえばコールの接続解除または保留の結果として、アプリケーションによるメディアの送受信が停止される場合は、CiscoRTPOutputStoppedEv イベントと CiscoRTPInputStoppedEv イベントが送信されます。これらのイベントは、2 つのエンドポイント間に存在する現在の RTP メディア ストリームをティアダウンする必要があることを意味します。

CallControlConnection.redirect() メソッドの事前条件の 1 つとして、CallControlConnection が CallControlConnection.OFFERING または CallControlConnection.ALERTING のどちらかの状態にあることが規定されています。Cisco Unified JTAPI では、CallControlConnection.ESTABLISHED 状態の Connection もリダイレクトできます。

redirect() メソッドには、CiscoConnection インターフェイス内に次のオーバーロードされた形式があります。これにより、コールのリダイレクト中に障害が起きたときに、必要な動作をアプリケーションによって指定し、コーリング サーチ スペースを指定したり、元の着信フィールドをリセットできます。

オーバーロードのリダイレクト メソッドにある次の INT パラメータの 1 つを CiscoConnection インターフェイスから渡すことで、アプリケーションに必要な動作を選択します。

• 障害時のリダイレクト ドロップ：コールが使用中または無効な送信先にリダイレクトされた場合、Cisco Unified Communications Manager では、リダイレクトが失敗した場合にコールを破棄するか、またはリダイレクト コントローラにコールを残す処理のどちらかを実行できます。この後、JTAPI アプリケーションを使用して、別の送信先にコールをリダイレクトするなどの修正処置ができます。リダイレクト モード パラメータには、次のオプションがあります。

  • CiscoConnection.REDIRECT_DROP_ON_FAILURE

  • CiscoConnection.REDIRECT_NORMAL

• コーリング サーチ スペース：リダイレクトでは、コーリング サーチ スペースのパラメータを使用して、使用する callingSearchSpace を指定します。アプリケーションでは、発信側のコーリング サーチ スペースまたはリダイレクト コントローラのコーリング サーチ スペースのどちらかを使用できます。このシナリオには、次のパラメータ オプションがあります。

  • CiscoConnection.CALLINGADDRESS_SEARCH_SPACE

  • CiscoConnection.ADDRESS_SEARCH_SPACE

• 元の着信のリセット：着信アドレス オプションのパラメータを使用して、元の着信フィールドをリセットします。このシナリオには、次のオプションがあります。

  • CiscoConnection.CALLED_ADDRESS_UNCHANGED

  • CiscoConnection.CALLED_ADDRESS_SET_TO_REDIRECT_DESTINATION このオプションでは、コールがリダイレクトの送信先に到着したときに、フィールドが影響を受けます。

詳細については、com.cisco.jtapi.extensions.CiscoConnection のドキュメントを参照してください。

A が B をコールし、B が C にリダイレクトし、C（リダイレクト先）がプロバイダーによって監視されたアドレスを表さない場合、JTAPI により、C について原因コード Ev.CAUSE_NORMAL で CallCtlConnAlertingEv が提供されます。リリース 5.0 よりも前では、このシナリオの原因コードは CiscoCallEv.CAUSE_REDIRECTED を指定していました。

この変更では、C がプロバイダーによって監視されている場合と監視されていない場合の動作の一貫性が維持されています。

（注）	同じシナリオで C が監視されている場合、5.0 よりも前のリリースでも C について CAUSE_NORMAL で CallCtlConnAlertingEv が提供されており、この動作は変更ありません。

Cisco Unified JTAPI アプリケーションは、優先される元の着信側 DN をリダイレクト要求内に指定できます。リダイレクト時の元の着信者 ID のセット機能により、別の宛先への Connection 上にあるコールをリダイレクトすることに加えて、アプリケーションが OriginalCalledID に任意の値を設定できます。これにより、アプリケーションは、コールを別のボイス メールへ直接転送できます。たとえば、A が B をコールし、B がコールを C Voice Mail へ転送する場合、アプリケーションは拡張リダイレクト要求内で、優先される元の着信者に C を、また C Voice Mail プロファイルに宛先を指定できます。この要求によって、C Voice Mail プロファイルにコールが表示され、Cisco Unified Communications Manager の originalCalledParty フィールドは C になります。一般的なボイス メール アプリケーションでは、originalCalledParty 情報の検索により、ユーザのボイス メールボックスが特定されます。

この機能は、元の着信者を変更してコールを特定の通話者へリダイレクトするあらゆるアプリケーションで使用できます。

（注）	この機能では、lastRedirectedAddress も、リダイレクト要求に指定された preferredOriginalCalledParty に変更されます。

次の callControlConnection インターフェイスが、リダイレクト時の元の着信者 ID のセットに適用されます。

Interface CiscoConnection Extends callControlConnection With Additional Cisco Unified Communications Manager-Specific Capabilities

インターフェイスの詳細については、Cisco Unified JTAPI 拡張を参照してください。リダイレクト時の元の着信者 ID のセットのメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

設定時には、デバイスをデバイス プール内に設定し、静的な Cisco Unified Communications Manager グループに割り当てる必要があります。デバイスは、コール制御のシグナリングを処理する特定の Cisco Unified Communications Manager サーバに登録されます。サーバに障害が起きると、デバイスはそのグループのバックアップ サーバにフェールオーバーされます。デバイスは、プライマリ サーバがオンライン状態に復旧し、デバイス上のアクティブ コールがなくなるまで待機した後で、プライマリ Cisco Unified Communications Manager サーバにリホームされます。Cisco Unified JTAPI では、バックアップ サーバへの登録中に、一時的なアウト オブ サービスのメッセージを送信することで、アプリケーションにこの移行が通知されます。

Cisco Unified JTAPI では、CTI Manager 経由での冗長性のための透過型アプリケーションも提供されます。プライマリ CTI Manager に障害が起きると、Cisco Unified JTAPI はバックアップ CTI Manager と自動的に接続され、この再接続がアプリケーションに伝えられます。これにより、1 台の Cisco Unified Communications Manager サーバに接続する代わりに、アプリケーションは CTIManager のセットに接続します。アプリケーションでは、JTAPI を呼び出すときに CTIManager サーバの名前を指定します。

Cisco Unified JTAPI と CTIManager では、両者間の接続切れを検出するために双方向のハートビート信号が維持されます。CTIManager によって、アプリケーションが作動していない状態が検出され、その割り当てられたリソースがクリーン アップされます。次の図は、「クラスタ内の JTAPI、CTIManager および Cisco Unified Communications Manager の論理表現」を示したものです。

（注）	Cisco Unified JTAPI では、プライマリ CTIManager に正常に接続された後、CTIManager への JTAPI 接続が失敗すると、プライマリまたはバックアップの CTIManager への再接続が交互に試みられます。

リリース 11.0(1) では、コールがゲートウェイまたはトランクで転送されるときの SIP 183 メッセージに対する Cisco JTAPI の応答方法が更新されました。確立されたコールがトランク経由で転送され、SIP 183 が受信されると、コールは Cisco JTAPI によって CallControlConnection.NETWORK_ALERTING 状態に移行します。コールが応答されると、Cisco JTAPI によってコール状態は CallControlConnection.ESTABLISHED に移行します。

新しい Cisco CallManager サービス パラメータ、[SDP による SIP 183 での CTI レポート Ringback（CTI Report Ringback on SIP 183 with SDP）] がこの機能を設定するために追加されました。このサービス パラメータを True に設定すると、上記の動作が適用されます。これがデフォルトの設定です。

アプリケーションが従来の動作を使用する必要がある場合は、サービス パラメータを False に設定できます。この設定では、コールがゲートウェイまたはトランクで転送される場合、CTI は CallControlConnection.NETWORK_REACHED 状態を使用して他のネットワークに達したことを報告しますが、接続が確立されたことは CTI によって報告されません。

JTAPI でのルーティングには、Cisco Unified Communications Manager 上の CTI ルート ポイントの設定が必要です。複数のコールをこのルート ポイントにキューイングできますが、CTI ルート ポイントのデバイス上に設定できるのは、1 本の回線だけです。

コール センター パッケージで説明されるように、補助ルーティングの JTAPI 実装には、次のアクションが含まれています。

• ルート アドレス上のルート コールバックを登録する

• 多様なルーティング イベント（routeSelect、routeEnd）への応答に対して適切なハンドラを作成する

  （注）

  CTI ルート ポイントは、同一回線上で同時に無制限の数の着信コールを処理できるデバイスを表します。コールに対しては、javax.telephony.callcenter パッケージのメソッドを使用したルーティング、あるいは javax.telephony.callcontrol パッケージのメソッドを使用した受け入れ、リダイレクト、または接続解除を実行できます。各 CTI ルート ポイントは、Cisco Unified Communications Manager の 1 回線だけで構成できます。1 つの CTI ルート ポイントでサポートされる回線の最大数は 34 です。34 を超える回線をサポートするには、ルート ポイントを追加します。CTI ルート ポイントの構成方法と管理方法の詳細については、『Cisco Unified Communications Manager Administration Guide』を参照してください。

次の図に CTI ルート ポイントの設定を示します。

この機能では、コールがセキュアかどうかアプリケーションに通知され、セキュアな電話会議を可能にします。コール全体のセキュリティ ステータスが変更されると、セキュア会議からは、コールでのイベントという形でアプリケーションに通知されます。コール全体のセキュリティ ステータスが変更されると、CiscoCallSecurityStatusChangedEv で全体的なコールのセキュリティ ステータスを受信します。端末が通話状態になると、JTAPI により、コールのセキュリティ ステータス情報がアプリケーションに配信されます。アプリケーションは、CiscoCall の新しいインターフェイスを使用して、コールのセキュリティ ステータスを照会できます。アプリケーションが既存のコールのモニタリングを始めると、アプリケーションではセキュリティ ステータス情報を参照できるようになります。

共有アドレスの場合、CiscoCallSecurityStatusChangedEv も Remote In Use の状態のアドレスにも報告されます。OverallCallSecurityStatus は、アクティブな端末で報告されるステータスと一致します。たとえば、A（暗号化）、B（暗号化）、C（認証済）および C'（認証済）という三者会議の場合、システムにより、C および C' に CiscoCallSecurityStatusChangedEv with OverallCallSecurityStatus = Authenticated が報告されます。このイベントは、コールごとに配信されます。

OverallCallSecurityStatus が Encrypted であるかどうかに関係なく、Secure Real-Time Protocol（SRTP）キー情報は引き続き暗号化されている通話者について送信されます。たとえば、A（暗号化）、B（暗号化）および C（セキュアでない）という三者会議の場合、電話会議の OverallCallSecurityStatus は NotAuthenticated です。ただし、暗号化されている通話者が含まれているため、A、B および会議ブリッジを繋ぐメディアは暗号化されたままです。したがって、OverallCallSecurityStatus に関係なく、A と B は SRTP キーを受信します。

この機能は、暗号化されたメディア セッションの Secure Real-Time Protocol（SRTP）キー情報を Cisco Unified Communications Manager をベースとするエンタープライズ システム内の認証済みエンド ポイント間で配信するために必要なメカニズムを提供します。このキー情報を受け取るには、Cisco Unified Communications Manager の管理者用ウィンドウで TLS Enabled フラグと SRTP Enabled フラグを設定し、JTAPI と CTIManager の間で TLS リンクを確立する必要があります。

キー情報は CiscoRTPInputKeyEv および CiscoRTPOutputKeyEv で公開されます。アプリケーションでこれらのイベントを受信するには、CiscoTermEvFilter の rtpKeyEvenabled を有効にする必要があります。デフォルトでは、下位互換性を維持するためにフィルタは無効になっています。フィルタを有効にすると、アプリケーションは常に CiscoRTPInputKeyEv と CiscoRTPOutputKeyEv を受信します。これらのイベントのセキュリティ インジケータは、メディアが暗号化されているかどうか、およびキーが使用可能かどうかを示します。

CiscoRTPInputKeyEv には入力ストリームのキー情報が含まれ、CiscoRTPOutputKeyEv には出力ストリームのキー情報が含まれます。このキー情報は、パケットを復号化してモニタリングを開始したり、メディアを録音する目的に使用できます。このキー情報は改ざん可能な形で保存してはならず、不要になったときはキーのエントリをゼロに戻すかクリアする必要があります。

このキー情報には次の項目が含まれます。

• Key Length

• Master Key

• Salt Length

• Master Salt

• AlgorithmID

• isMKIPresent

• Key Derivation Rate

この機能拡張では、CTIPort と RoutePoint におけるセキュアなメディア終端もサポートされています。これを行うには、サポートされている暗号化アルゴリズムを CTIPort とルート ポイントの登録要求で渡します。TLS リンクが存在せず SRTP Enabled フラグが設定されていない場合は、アプリケーションにエラーが返されます。メディアが暗号化されるかどうかは、相手側がセキュア メディア対応かどうか、およびアルゴリズムのネゴシエーションが成功するかどうかによって決まります。

コール中のモニタリングに関しては、2 つのエンド ポイント間でコールが確立された後にアプリケーションが起動された場合、アプリケーションは Terminal.createSnapshot() とスナップショット イベント CiscoTermSnapshotEv を照会する必要があります。CiscoTermSnapshotCompletedEv が送信され、エンド ポイント間の現在のメディアがセキュアかどうかが示されます。アプリケーションは CiscoMediaCallSecurityIndicator を照会してコールのセキュリティ インジケータを取得できますが、この場合はイベントにキー情報が含まれません。端末のどの回線にもコールが存在しない場合、アプリケーションは CiscoTermSnapshotCompletedEv だけを取得します。下位互換性を維持するため、これらのイベントはアプリケーションで CiscoTermEvFilter の snapShotRTPEnabled フィルタが有効にされた場合に限り生成されます。

1 つのコールに関連する RTP イベントを相互に関連付けることができるように、すべての RTP イベントに CiscoRTPHandle が追加されます。下位互換性を維持するため、セキュアなメディアが存在しない場合、新しいイベントは生成されません。

SRTP の詳細については、SourceForge.net の『Secure RTP Library API Documentation』（David McGrew 著）を参照してください。

次のセクションでは、SRTP キー情報に関するインターフェイスの変更点について説明します。

この機能を使用すると、セキュリティ保護されたコールを Cisco JTAPI でサイレント モニタリングおよび録音できます。コールのモニタリングおよび録音は、Cisco Unified Communications Manager のリリース 6.0 で導入されましたが、セキュアなコールのモニタリングおよび録音はサポートされていませんでした。今回のリリースでは、セキュリティ保護されたコールもこの機能の対象となります。この機能拡張では、スーパーバイザまたは録音側のデバイスのセキュリティ機能がエージェントのセキュリティ機能と同じかまたはそれよりも高い場合、セキュリティ保護されたコールをモニタリングまたは録音できます。モニタリングの開始側が使用するデバイスのセキュリティ機能がエージェントのセキュリティ機能よりも低い場合、モニタリング要求は失敗します。認証デバイスで録音が試行される場合、または録音側のセキュリティ機能がセキュリティ保護されておらず、エージェントのセキュリティ機能が暗号化されている場合、録音要求は失敗します。

エージェントのセキュリティ機能をスーパーバイザが満たしていないためにモニタリング要求を拒否された場合、Cisco JTAPI は CTIERR_SECURITY_CAPABILITY_MISMATCH で PriviledgeViolationException をスローします。新しい API getTransactionID() が、CiscoTermConnMonitorInitiatorInfoEv および CiscoTermConnMonitorTargetInfoEv に追加されます。

モニタリング セッションが終了するときに、CiscoJTAPI は、新しいイベント CiscoAddrMonitoringTerminatedEv を配信します。このイベントは、セキュリティ保護されたモニタリング セッションを開始し、モニタリング コールからドロップしたスーパーバイザに配信されます。

新しい API の getCiscoAddrMonitoringTerminatedEvFilter() および setCiscoAddrMonitoringTerminatedEvFilter() が、アプリケーションのインターフェイス CiscoAddrEvFilter に追加され、CiscoAddrMonitoringTerminatedEv のフィルタ値が取得または設定されます。フィルタはデフォルトで True に設定されており、イベントが配信されます。このイベントの受信を停止するには、アプリケーションによりフィルタを False に設定する必要があります。

前述のとおり、モニタリング コール（モニタリングの開始側によって使用されているコール）で会議に参加した場合、最終コールはモニタリングのターゲットと接続していない可能性があります。モニタリングの開始側が別の通話者をモニタリング コールの会議に追加すると、両者にモニタリング ターゲットと発信者との間の音声が聞こえます。

SelectRoute インターフェイスが拡張されて、PreferredOriginalCalledNumber パラメータと PreferredOriginalCalledOption パラメータを取るようになりました。これにより、コールがルーティングされるときに、OriginalCalled 値を指定された PreferredOriginalCalledNumber に再設定することが可能になりました。このインターフェイスは、PreferredOriginalCalledNumber、PreferredOriginalCalledOption のリストを取り、それらを RouteSelected リストに対応付けます。RouteSelected リストのインデックス I にある Route にコールがルーティングされる場合、インデックス I の PreferredOriginalCalledNumber と PreferredOriginalCalledOption が使用されます。パラメータのさまざまな値によって、アプリケーションは次のように動作します。

（注）

以降の説明で x は、コールがルーティングされるインデックスを示します。たとえば、コールがルート n にルーティングされると、x の値は n になります。インデックス x の PreferredOriginalCalledOption が無効であるか範囲外の場合、JTAPI により値は CiscoRouteSession.DONOT_RESET_ORIGINALCALLED のデフォルト値に戻されます。PreferredOriginalCalledOption が null の場合、すべてのルーティングが CiscoRouteSession.DONOT_RESET_ORIGINALCALLED により実行されます。

（注）	OriginalCalled が PreferredOriginalCalled に設定されると、LastRedirectingParty 番号も PreferredOriginalCalled に再設定されます。

SelectRoute インターフェイスの拡張には、次の新しいインターフェイスまたは変更されたインターフェイスがあります。

PreferredOriginalCalledOption には次のいずれかの値を指定できます。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。SelectRoute インターフェイスの拡張のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

selectRoute() には、機能プライオリティとコーリング サーチ スペースを配列で持っています。この API では、選択したルートごとに、異なる機能プライオリティとコーリング サーチ スペースが柔軟に提供されます。

SetMessageWaiting インターフェイスは、アドレスのメッセージ待ちランプまたはインジケータを、アプリケーションで設定するためのメソッドを提供します。このメソッドは、送信先と同じパーティションにあるアドレス上で呼び出します。

次のインターフェイスでは、destination で指定したアドレスに対して、メッセージ待ちインジケータを有効または無効にする必要があるかどうかが指定されます。enable が true の場合は、メッセージ待機が有効になります（すでに有効になっている場合はそのまま）。enable が false の場合は、メッセージ待機が無効になります（すでに無効になっている場合はそのまま）。

{ public void setMessageWaiting (java.lang.String destination, boolean enable) throws javax.telephony.MethodNotSupportedException, javax.telephony.InvalidStateException, javax.telephony.PrivilegeViolationException

}

共用回線は、複数端末での同じ DN のアピアランスを表します。CiscoJtapi は、共有回線をサポートします。共有回線では、同じ DN を持つ他の共有回線端末上で別のコールがアクティブになっていても、共有 DN 端末の制御、特定の共有 DN 端末にあるコールの保留と別の共有 DN 端末からの保留解除、2 本の共有回線間での発呼、特定の共有回線端末からのコール開始を、アプリケーション側から実行できます。

共用回線には、次のインターフェイスがあります。

• CiscoAddress.getInServiceAddrTerminals()：アドレスがイン サービス状態にある端末の配列を返します。

  Terminal {} getInServiceAddrTerminals();

• CiscoAddrOutOfService.getTerminal()：アウト オブ サービスの端末を返します。

  Terminal getTerminal();

• CiscoAddrInService.getTerminal()：イン サービスの端末を返します。

  Terminal  getTerminal();

• CiscoConnection.setRequestController(TerminalConnection tc)：Connection に関連付けられた terminalConnection をアプリケーション側で選択して、パーク、リダイレクト、または接続解除操作を実行できるようにします。SharedLine のシナリオで複数の TerminalConnection がアクティブになっている場合に、これが必要になります。

• CiscoConnection.getRequestController()：アプリケーションが要求コントローラとして設定する TerminalConnection を返します。

• CiscoAddrAddedToTerminalEv：次の条件が発生すると送信されます。

  • SharedDN を含む user controlList に端末またはデバイスが追加され、アプリケーションにイベントが送信された。つまり、ユーザのアドレスがコントロール リストにあり、コントロール リストの同じアドレスに新しいデバイスを追加した場合、このイベントが送信されます。

  • EM（エクステンション モビリティ）ユーザが、SharedDN を含むプロファイルを使用して端末にログインした。この場合、このイベントは、既存のアドレスに新しい端末が追加されたことを通知します。

  • ユーザ コントロール リスト内のデバイスに新しい SharedDN が追加された。

  getTerminal() インターフェイスは、アドレスに追加される端末を返します。

  getAddress() インターフェイスは、新しい端末が追加されるアドレスを返します。

• CiscoAddrRemoveFromTerminalEv：次の条件が発生すると送信されます。

  • SharedDN を含む user controlList から端末またはデバイスが削除された。つまり、ユーザのコントロール リスト内の共有アドレスを使用したデバイスがコントロール リストから削除された場合、このイベントが送信されます。

  • SharedDN を含むプロファイルが使用されている端末から、EM（エクステンション モビリティ）ユーザがログアウトした。このイベントは、端末のうち 1 台が既存のアドレスから削除されたことをアプリケーションに通知します。

  • ユーザ コントロール リスト内のデバイスから新しい SharedDN（SharedLine）が削除された。

  getTerminal() インターフェイスは、アドレスから削除される端末を返します。

  getAddress() インターフェイスは、端末が削除されるアドレスを返します。

共用回線の変更された動作または新しい動作を次に示します。

• CiscoAddress イベントの動作には、次の変更点があります。

  • JTAPI アプリケーションは、共用回線アドレスの複数の CiscoAddrInServiceEv を受信します。アプリケーションは、CiscoAddrInServiceEv.getTerminal() を使用して、アドレスがイン サービスの端末を取得できます。

  • JTAPI アプリケーションは、共用回線アドレスの複数の CiscoAddrOutOfServiceEv を受信します。アプリケーションは、CiscoAddrInServiceEv.getTerminal() を使用して、アドレスがアウト オブ サービスの端末を取得できます。

  • 最初の共用回線がイン サービスになると、アドレスの状態がイン サービスになります（最初の CiscoAddressInServiceEv が受信されたときなど）。

  • 最後の共用回線がアウト オブ サービスになると、アドレスの状態がアウト オブ サービスになります（最後の CiscoAddressOutOfServiceEv が受信されたときなど）。

• 着信コールの場合、共用回線のすべての回線アピアランスが鳴ります。これは、アプリケーションに対しては、1 つのアクティブ コール（callActiveEv）、1 つの Connection（ConnCreatedEv）、および複数の terminalConnection（共用回線あたり 1 件の TermConnCreatedEv）として示されます。

• コールは、すべての端末に対して示されます。コールが呼び出し状態になっている場合、TerminalConnection の状態は呼び出し中です。共用回線が応答すると、TerminalConnection は Active 状態に、共用回線上にあるその他の TerminalConnection は Passive 状態になり、その時点のすべての共用回線の callControlTerminalConnection は Bridged 状態になります。コールが保留にされると、すべての TerminalConnection は Active 状態に、callControllTerminalConnection は HELD 状態になります。この時点では、どの端末でもコールを取得できます。取得する側の端末では、terminalConnection が Active 状態のまま callControlTerminalConnection が Talking 状態になり、その他のすべての共用端末の terminalConnection は Passive 状態になります。同時に、CallControlTerminalConnection が HELD 状態から Bridged 状態に変わります。

• ある共用回線から、同じ DN を持つ別の共用回線に発呼できます。この場合、コールには 1 つの Connection と複数の TerminalConnection が含まれます。

• ある共用回線から同じ DN を持つ別の共用回線に発呼する場合、事後条件は 1 つの Connection だけになります。

• 2 つの TerminalConnection がアクティブになっている共用回線 Connection（割り込みなど）の場合、Connection.Disconnect() を実行しても接続解除されません。

  Passive 状態または Bridged 状態の TerminalConnection が 1 つしかない 1 つの SharedDN Connection だけをアプリケーションがモニタしている場合、この Connection に対してどんな API を呼び出しても PreConditionException が発生します。

• 前述のシナリオと同様に、アプリケーションがモニタしているコールのすべての Connection に Passive 状態または Bridged 状態の TerminalConnection しかない場合、このコールに対するすべての API が PreConditionException をスローします（Call.Drop() など）。

• 共用回線上に複数の Active 状態の TerminalConnection がある場合、次のシナリオにおいて Call.drop() は CallInValid を返しません。

  • A が A' との SharedLine で、A' がコールに割り込んでいる、A と B の 2 者間コールの場合。

    アプリケーションは A' および B をモニタしません。アプリケーションが Call.drop() を発行した場合、A' の TerminalConnection は Passive 状態になりますが、コールは無効になりません。

  • 前述同様に、A、A'、A"、B が電話会議を行っている場合。

    アプリケーションは A および A' だけをモニタするので、Call.drop() を実行してもコールは無効になりません。A および A' の TerminalConnection だけがパッシブになります。

  • A、A'、B、B' が SharedLine アドレスである場合。

    A が B をコールし、B が応答し、A' と B' がコールに割り込みます。アプリケーションは A および B だけをモニタします。この場合、Call.drop() により A および B の TerminalConnection は Passive 状態になりますが、コールは無効になりません。

• TerminalConnection が Passive 状態または Bridged 状態、あるいは Passive/InUse 状態にある場合、TerminalConnection() ですべての API が PreConditionException をスローします。Passive または Bridged 状態では、TerminalConnection で API 端末の ConnectionJoin()（割り込みと呼ばれる）だけを使用できます。TerminalConnection は、現在 TerminalConnection Join() をサポートしていません。

• Connection 上に Active 状態または Talking 状態の複数の TerminalConnection がある場合、アプリケーションは一方を終了してから、この Connection に対して Redirect()、Park()、Disconnect() などの API を発行する必要がある可能性があります。Connection.setRequestController（TerminalConnection tc）API を使用して、TerminalConnection を選択できます。

• SharedLine 端末上のコールが保留され、アプリケーションが Connection.Disconnect () を発行した場合、アプリケーションは Connection.setRequestController（TerminalConnection tc）API を使用して特定の TerminalConnection を設定できます。requestcontroller が設定されていない場合、すべての HeldTerminalConnection が破棄され、Connection が解除された状態になります。1 つの HeldConnection だけが破棄された場合、その他の SharedLines 端末上にコールが残ります。破棄された端末からはコール アピアランスがなくなるため、このコールに対して、この端末が割り込んだり、機能の操作に参加したりすることはできなくなります。

インターフェイスの変更点については、Cisco Unified JTAPI 拡張を参照してください。共用回線のメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

JTAPIInstaller でサイレント インストール呼び出しを実行すると、アプリケーションのインストールに JTAPIInstaller を組み込むことができます。 で説明しています。システムに SD よりも前のバージョンが存在し、SD バージョンへのアップグレード操作が発生した場合、新しいインストーラによって、SD よりも前のバージョンのアンインストーラが自動的に呼び出されます。アプリケーションで JTAPI の SD よりも前のバージョンをサイレント モードでアンインストールする必要がある場合、次の方法でコマンドラインからインストーラを起動する必要があります。CiscoJtapiClient.exe -W newversion.silent = 1。このメソッドは、Windows プラットフォームにだけ適用されます。新しい SD インストーラのインストール前、つまりインストーラを実行する前に、アプリケーションで JTAPI のバージョンを検出する必要がある場合は、次のコマンドを使用して検出を行ってください。

CiscoJtapiClient.exe silent -W newversion.check = 1 goto showversion このコマンドをコマンドラインから実行すると、インストーラにより、カレント ディレクトリに jtapiversion.txt というファイルが作成されます。これにより JTAPI バージョンのインストーラが a.b(c.d) 形式になります。このコマンドは、Linux および Windows プラットフォームに適用されます。

IP Phone を使用したサイレント モニタリング機能を提供します。この場合の発信者は、モニタリングのターゲットをコールするか、そこからコールを受信する側のエンド ポイントを表します。モニタリングのターゲットはモニタリングの対象側（コール センターの場合エージェント）で、モニタリング側はモニタリングの開始側（スーパーバイザ）です。

録音機能により、アプリケーションは任意のモニタリング対象アドレスの会話を録音できます。3 つの録音設定があります。

サイレント モニタリング機能により、アプリケーションは他の 2 者間の会話をライブで傍受できます。モニタリングの開始側は、モニタリングのターゲットおよび発信者のいずれとも通話できません。機能は、法律への準拠が必要な場合に通知トーンを提供します。

モニタリングは、アプリケーションの要求によってだけ開始されます。アプリケーションは、モニタリングする各コールに対し、そのつど、モニタリング要求を送信する必要があります。接続状態にあるコールだけをモニタリングできます。モニタリングの要求が確立されると、モニタリングのターゲットと発信者間の音声ストリームがモニタリングの開始側にストリーミングされます。次のような場合、モニタリングのターゲットはトーンを受信します。

• モニタリングのターゲットがトーンを受信するように設定されている場合、または

• アプリケーションにより、モニタリングの開始時にトーンを鳴らすように要求されている場合

アプリケーションは、Standard CTI Allow Call Monitor ユーザ グループに属する場合コールをモニタリングでき、コンタクト センター外で使用することもできます。モニタリングに関するイベントは、すべてのコール オブザーバに配信されます。

「Monitor」は予約語であるため、システム内の回線の表示名としては設定できません。" "「Conference」、「Park Number」、「Barge」、「CBarge」も予約語です。" "" "" "" "

モニタリング セッションが確立されると、モニタリング開始側の端末オブザーバが Cisco RTP イベントを受信します。サイレント モニタリングのコールではメディアが一方向にしか流れませんが、getMediaConnectionMode() は CiscoMediaConnectionMode.RECEIVE_ONLY の代わりに CiscoMediaConnectionMode.TRANSMIT_AND_RECEIVE を返します。CTIPort がモニタリング開始側として使用されている場合、アプリケーションでは CiscoMediaOpenLogicalChannelEv から同じ動作を受信する可能性があることを考慮する必要があります。

モニタリング コール（モニタリングの開始側によって使用されているコール）で会議に参加した場合、最終コールはモニタリングのターゲットと接続しません。モニタリング開始側が別の通話者をモニタリング コールの会議に追加すると、両者にモニタリング ターゲットと発信者との間の音声が聞こえます。

次のインターフェイスは TermConnEv を拡張し、コール オブザーバに配信されます。共有回線の場合、通話中の TerminalConnection のアドレスまたは端末上のコール オブザーバに、これらのイベントが配信されます。端末の Connection が INUSE または BRIDGED 状態だけの場合、アプリケーションはイベントを受信しません。

CiscoTermConnMonitoringStartEv

CiscoTermConnMonitoringStartEv

モニタリングの開始を示し、モニタリング ターゲットのコール オブザーバに配信されます。このイベントに対して getMonitorType() を使用すると、モニタリングのタイプを返します。

CiscoTermConnMonitoringEndEv

CiscoTermConnMonitoringEndEv

モニタリングの終了を示し、モニタリング ターゲットのコール オブザーバに配信されます。

CiscoTermConnMonitorInitiatorInfoEv

モニタリングの開始側の情報が公開され、モニタリング ターゲットのコール オブザーバに配信されます。このインターフェイスには次のメソッドがあります。CiscoMonitorInitiatorInfo getCiscoMonitorInitiatorInfo ()

モニタリングの開始側の端末名およびアドレスを公開する CiscoMonitorInitiatorInfo を返します。

CiscoTermConnMonitorTargetInfoEv

モニタリングのターゲットの情報が公開され、モニタリング ターゲットのコール オブザーバに配信されます。このインターフェイスには次のメソッドがあります。CiscoMonitorInitiatorInfo getCiscoMonitorTargetInfo()

モニタリングのターゲットの端末名およびアドレスを公開する CiscoMonitorInitiatorInfo を返します。

2 つの新しいエラー コードにより、モニタリングの失敗がアプリケーションに通知されます。

• CTIERR_PRIMARY_CALL_INVALID は、コールがアイドル状態になるか転送されたことが原因でモニタリングの要求が失敗し、例外が発生した場合に、CiscoException.getErrorCode() によって返されます。

• CTIERR_PRIMARY_CALL_STATE_INVALID は、モニタリングを開始できない状態にコールが移行したことが原因でモニタリングの要求が失敗した場合に返されます。

このリリースでは、新しい AddressType、MONITORING_TARGET が導入されています。JTAPI では、モニタリングのターゲット アドレスとして、このタイプのアドレスに Connection を作成します。この値は、CiscoAddress.getType() によって返されます。

シングル サインオン機能を使用すると、Cisco JTAPI アプリケーションはユーザ ID とパスワードの代わりにシングル サインオン チケットを使用して認証を行うことができます。

アプリケーションは、OpenSSO サーバに対するサービス チケットをアクティブなディレクトリからフェッチし、そのチケットを、getProivder(String str) API で使用されている文字列内の Cisco JTAPI へ渡します。アプリケーションはシングル サインオン チケットを ssoticket = "ssotokenfromad" として設定できます。

この機能を使用できるのはエンド ユーザのみです。

この機能を使用するアプリケーションは、getProvider 文字列にユーザ ID とパスワードを指定する必要はありません。

エンド ユーザがアプリケーションを使用しており、Standard CTI Secure Connection ロールが有効になっている場合は、プロバイダー文字列にユーザ ID が必要になります。パスワードは必要ありません。

この方法は、Kerberos 環境のアクティブ ディレクトリで Windows デスクトップのシングル サインオンを実現することを目的としています。Kerberos 環境のアクティブ ディレクトリを使用できない場合でも、別の同等な構成をセットアップできます。これには KDC、認証サーバ、およびドメイン コントローラが含まれます。

コード例

String ssoticket  =  getSSOticket(); //application implementation
String providerString  =  cucmserver + ssoticket +";";
JtapiPeer peer  =  JtapiPeerFactory.getJtapiPeer ( null );
try
{
  Provider provider  =  peer.getProvider (providerString);
}
catch (Exception exp )
{
  if ( exp instanceof PlatformException)
  {
    switch (((CiscoJtapiException)exp).getErrorCode() )
    {
    case CiscoJtapiException. CTIERR_SSO_DISABLED:
      System.out.println("SSO feature not enabled on CUCM ");
      break;
    case CiscoJtapiException. CTIERR_SSO_AUTH_SERVER_DOWN:
      System.out.println("server down");
      break;
    }
  }
  else
  {
    System.out.println("Exception  =  " + exp.toString());
  }

}      

このインターフェイスを使用すると、アプリケーションが特定のアドレスにコールを転送できます。Cisco Unified JTAPI は、JTAPI 1.2 仕様の定義に従って引き続きこのインターフェイスをサポートします。ただし、アプリケーションに配信されるイベントが Cisco Unified JTAPI の以前のバージョンから変更されています。

Cisco Unified JTAPI の以前のバージョンでは、このインターフェイスが使用されると、元のコールは保留状態になり、転送コントローラと宛先の間で新しいコールが作成されました。転送が正常に終了すると、転送コントローラ上の両方のコールが IDLE 状態になります。転送に失敗した場合、元のコールは HELD 状態のままになり、アプリケーションがコールを取得します。転送処理の開始時および完了時に、CiscoTransferStart および終了イベントがアプリケーションに配信されます。

アプリケーションには次のような変更があります。

• 新規コールが作成されない。

• CiscoTransferStartEv および CiscoTransferEndEv がアプリケーションに送信されない。

• 転送操作が失敗した場合も元のコールの状態が維持される。

このインターフェイスの事前条件および事後条件に変更はありません。

シングル ステップ転送に関するメッセージ フローを確認するには、メッセージ シーケンスの図を参照してください。

SIP リダイレクト サーバは SIP 要求を受信すると 3xx（リダイレクション）応答を返して、別の SIP アドレスにコンタクトするようクライアントに指示します。この機能拡張では、RFC 3261 に準拠した Cisco Unified Communications Manager リダイレクション（3xx）コール制御プリミティブがサポートされます。Cisco Unified Communications Manager リダイレクション プリミティブは SIP 3xx 応答を処理して、3xx 応答に含まれる各コンタクト アドレスに対して順次ハントを実行します。Cisco Unified Communications Manager はまた、この操作の結果として発生する機能対話も処理します。Cisco Unified JTAPI は、このプリミティブの結果として Connection と TerminalConnection がいつ作成され、破棄されたかを示す新しい原因コードをすべての CallEv で公開します。

リダイレクション プリミティブがターゲットをハントしているときに JTAPI Redirect や CallForwardNoAnswer などの機能対話が発生した場合は、lastRedirectAddress が変更されることがあります。ターゲットが応答せず、Cisco Unified Communications Manager リダイレクトがコールの制御を引き継いで次のターゲットにコールを送信する場合、lastRedirectAddress は最初に SIP 3xx 応答を返した通話者に設定されます。

SIP 3xx 応答に Diversion ヘッダーが含まれている場合、3xx プリミティブは lastRedirectParty に対して Diversion ヘッダーの最初の値を使用し、JTAPI アプリケーションは Diversion ヘッダー要素を lastRedirectAddress として認識します。

JTAPI では、下位互換性を維持するために、CM_REDIRECTION という原因を含む新しい API、CiscoCallEv.getCiscoFeatureReason() を CiscoCallEv インターフェイスで公開しています。

（注）	アプリケーションを開発する際には、この API から新しい機能固有の原因コードが返される可能性があることを考慮し、認識不能な原因コードに対してはデフォルトの動作を実行するようにしてください。

次のセクションでは、SIP 3XX Redirection に関するインターフェイスの変更点について説明します。

このリリースの Cisco Unified Communications Manager では、SIP を実行する電話を登録して SCCP を実行する電話と相互運用することができます。以降のセクションでは、SIP を実行する電話をサポートするために導入された新しいインターフェイスに加えて、SCCP をサポートする電話と比較した場合の動作の制限および相違点について説明します。既存のすべての機能が SIP を実行する電話でサポートされるわけではありませんが、JTAPI のイベントとインターフェイスの点で、SIP を実行する電話の全般的な動作は SCCP を実行する電話とほぼ同じです。

JTAPI アプリケーションで制御できるのは SIP を実行する Cisco Unified IP Phone 7900 シリーズ（Cisco Unified IP 7970 フォンなど）だけです。Cisco Unified IP 7960 や 7940 などの SIP プロトコルを実行する電話機はアプリケーションのコントロール リストに含めないでください。また、サードパーティ製の SIP を実行する電話も JTAPI アプリケーションでは制御できないので、コントロール リストには含めないでください。

以前のリリースでは、JTAPI は SIP を実行する電話で初期的なフィーチャ セットをサポートしていました。このリリースでは、SIP を実行する電話で次の機能のサポートが追加されました。

• SIP を実行する電話のパーク

• SIP を実行する電話のパーク解除

ヒント	SIP を実行する電話と SCCP フォンでは、コンサルト コールのイベントの順序が異なります。次のような例が考えられます。

1. 端末 A が共用回線 B/B' にコールを発信します。
2. 共用回線が端末 C にコンサルト コールを発信します。

   共有回線が SIP デバイスの場合、次のコール イベントが発生します。

   • B（アクティブ）は OnHold -> Select -> NewCall の順に受信します。

   • B'（使用中のリモート）は Select -> NewCall -> OnHold の順に受信します。

   ただし、共用回線が SCCP デバイスの場合、コール イベントは両方の端末で Select -> OnHold -> NewCall の順になります。

   アプリケーションがモニタリングだけを行っている場合、call.getConsultingTerminalConnection() によって null が返される可能性があります。

JTAPI は SIP を実行する電話で次の機能をサポートしています。

• Call.connect、offhook

• answer、disconnect、drop、hold、unhold

• consult、transfer、conference、redirect

• playdtmf、deviceData

JTAPI は SIP を実行する電話で次のイベントをサポートしています。

• CiscoTermDeviceStateEv、RTP イベント、inService および OutOfService

• MediaTermConnDtmfEv（アウトバンド専用）、転送開始および終了イベント、会議の開始および終了イベント、CiscoToneChangedEv および CiscoTermConnPrivacyChangedEv

SIP を実行する電話の動作は、次の点で SCCP を実行する電話と異なります。

• コール拒否：SIP を実行する電話に対してコールが発信されたとき、電話はそのコールを拒否することを選択できます。この場合、アプリケーションはその SIP 端末のアドレスに関する CallActive, ConnCreatedEv を受信した後に ConnDisconnectedEv を受信します。これは RP がコールを拒否した場合とほぼ同じです。

• メディアのないコンサルト コールに SIP フォンが含まれている場合は、接続後 1.5 秒以内に転送する必要があります。

• SIP を実行する電話では常に一括ダイヤルが使用されます。これはユーザが最初にオフフックしてから番号をダイヤルする場合も同じです。SIP フォンはすべての番号を収集してから、その番号を Cisco Unified Communications Manager に送信します。そのため、CallCtlConnDialingEv は常に、いずれかの設定済みダイヤル パターンに一致する桁数の番号が電話機で押された後に配信されます。

• MediaTermConnDtmfEv を受信するには、すべてのデバイスに対して「アウトオブバンド DTMF」を設定する必要があります。" "

CTI ポート、ルート ポイント、および SCCP を実行する電話に関するイベントは変更されていません。

トランスポートとして UDP を使用して SIP を実行する Cisco Unified IP Phone 7900 シリーズ モデルと Cisco Unified Communications Manager の間の接続が失われると、JTAPI アプリケーションはその電話機に対して定義されている端末とアドレスに関するイベント CiscoTermOutOfServiceEv と CiscoAddrOutOfServiceEv を受信します。UDP ではその性質上、接続切れが検出されるまでに時間差が生じるため、アプリケーションにアウト オブ サービス イベントが通知された後でも SIP を実行する Cisco Unified IP Phone 7900 シリーズは登録されているように見える場合があります。

Cisco Unified IP Phone 7960、7940、および SIP を実行する Cisco Unified IP Phone 7900 シリーズ以外がコントロール リストに含まれている場合、オブザーバ（オブザーバとコール オブザーバの両方）がアドレスまたは端末に追加されて CiscoTermRestrictedEv がプロバイダー オブザーバに配信されると、例外がスローされます。これらのイベントの原因は CiscoRestrictedEv.CAUSE_UNSUPPORTED_PROTOCOL です。

端末が SCCP を実行する電話か SIP を実行する電話かを示す新しいインターフェイス getProtocol() が CiscoTerminal で公開されました。getProtocol() が返す値は CiscoTerminalProtocol で定義されています。

CiscoCall に定義されている次の新しいインターフェイスにより、アプリケーションは外部の SIP エンティティの URL 情報を取得できます。

REFER は RFC 3515 で定義されている SIP メソッドです。REFER メソッドは、受信者（Request-URI によって識別される Referee）に対して、要求で提供されたコンタクト情報を使用して第三者（ターゲットと呼ばれる）にコンタクトするよう指示します。この REFER メソッドを使用すると、REFER を送信した端末（Referrer）はリクエストの結果を受け取ることができます。

Cisco Unified Communications Manager はバックツーバック ユーザ エージェント（B2BUA）として、内部ダイアログと外部ダイアログの両方で、Referee の代わりにインバウンド REFER を処理します。REFER の結果として、Cisco Unified Communications Manager は Referee と Refer To Target の間にコールを作成します。Referrer と Referee の間に既存のコールが存在する場合は、REFER が完了した後に Referrer 側でコールがドロップされます。

REPLACES 機能は既存の SIP ダイアログを新しいダイアログに置き換えます。SIP ダイアログが 2 つの SIP ユーザ エージェント間のコールであるのに対し、Cisco Unified Communications Manager ダイアログは半コール（コール レッグ）です。REPLACES 機能は REFER または INVITE によって開始されます。Cisco Unified Communications Manager は REPLACES ヘッダーの受信者の代わりに REPLACES 要求を処理します。この要求は新しいダイアログに関連付けられ、REPLACES ヘッダーで指定されている既存のダイアログ（コール）の相手側に代わりにコールに参加したい通話者が要求者になります。Cisco Unified Communications Manager は REPLACES ヘッダーで指定されているダイアログ（コール）の接続を解除して、要求者を接続します。

JTAPI は、Cisco Unified Communications Manager の REFER 機能と REPLACE 機能によって発生するコール イベントを JTAPI コール モデルでモデル化するように拡張されており、これらのコール イベントをアプリケーションで処理することを可能にします。JTAPI には REPLACES 要求を使用して REFER または REFER/INVITE を開始するためのインターフェイスはありませんが、これらのコール イベントを適切に処理することは可能です。

これら 2 つの機能には下位互換性があります。JTAPI は REFER/REPLACE によって発生したイベントを CAUSE_NORMAL で提供します。機能固有の原因は、新しいインターフェイスである CiscoCallEv.getCiscoFeatureReason() から取得できます。

（注）	このインターフェイスは現行機能と新機能の両方に関して機能固有の原因を提供しますが、将来のリリースでは後方互換性はなくなる予定です。アプリケーションでこのインターフェイスを使用する場合は、将来的な下位互換性の問題を回避するために、デフォルトの処理を実装する必要があります。

次のセクションでは、SIP の REFER/REPLACE に関するインターフェイスの変更点について説明します。

com.cisco.jtapi.extensions
Interface CiscoCallEv

SIP トランク アーリー オファー機能により、SIP トランクはアーリー オファーの発信コールをサポートできます。メディア機能および電話のポート情報を使用できる場合は、SIP トランクはメディア ターミネーション ポイント（MTP）を使用しません。

メディア ポート情報が使用できない場合、Cisco Unified Communications Manager は MTP を割り当ててオファーを提供します。

アプリケーションでこの機能が有効にして、SIP トランクを通過するコールを作成する場合には、メディアが確立される前であっても、Cisco Unified Communications Manager は IP アドレスを持ち、登録されている端末のポート情報を持っている必要があります。これにより、MTP が不要になります。

JTAPI の観点から見た変更点は次のとおりです。

• 新しいインターフェイス CiscoBaseMediaTerminal は CiscoTerminal を拡張している。

• 新しい register() API は次の引数をとる。

  • IP アドレス

  • [ポート（Port）]

  • メディア機能

  • アルゴリズム ID

  • IP_V6 アドレス

  • アドレッシング モード

  • 登録タイプ

アプリケーションは register() API を使用して、CiscoMediaTerminal および CiscoRouteTerminal を、CiscoBaseMediaTerminal で使用できる次の登録タイプで登録します。

• CiscoBaseMediaTerminal.NO_MEDIA_REGISTRATION（ルート ポイントでのみ使用可能）

• CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION（CTI ポートおよびルート ポイントの動的登録）

• CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT

• CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION（CTI ポートの静的登録）

• CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT

（注）	アプリケーションは、ルート ポイントおよび CTI ポートに対して CiscoRouteTerminal および CiscoMediaTerminal 上の register() API を使用して登録タイプを指定します。

この機能を有効にするには、次のいずれかを選択します。

• CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT（CTI ポートまたはルート ポイントを動的に登録するための登録タイプ）

• CiscoBaseMediaTermial.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT（CTI ポートまたはルート ポイントを静的に登録するための登録タイプ）

アプリケーションでこの機能を有効にしており、SIP トランクを通過するコールを開始している場合は、CiscoJTAPI は新しいイベント CiscoMediaOpenIPPortEv を配信します。このイベントを受け取ると、アプリケーションは API getRegistrationType() を使用して登録タイプを問い合わせます。この API はこのインターフェイス上で公開され、返される値に基づいて次の処理を実行します。

• 戻り値が CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT の場合、アプリケーションは RTP パラメータを設定しポートを開く必要があります。現在、アプリケーションは動的に登録された CiscoMediaTerminal および CiscoRouteTerminal に対して CiscoMediaOpenLogicalChannelEv を受け取る際に、RTP パラメータを設定します。

• 戻り値が CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT の場合、アプリケーションはポートを開く必要があります。現在、ほとんどのアプリケーションは、RTP イベントを受け取ったときに、静的に登録されている端末を開きます。

アプリケーションがある端末を登録しようとして、その端末がすでに CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT または CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT の登録タイプで登録されている場合は、JTAPI は別の登録タイプを使用して、それぞれエラー コード CiscoJtapiException.CTIERR_MEDIA_ALREADY_TERMINATED_DYNAMIC_GETPORT_SUPPORT、CiscoJtapiException.CTIERR_MEDIA_ALREADY_TERMINATED_STATIC_GETPORT_SUPPORT で PlatformException をスローします。

インターフェイス CiscoMediaOpenLogicalChannelEv では新しい API isRTPRequired() も公開されており、アプリケーションがこのイベントを受け取ったときに、アプリケーションが RTP パラメータを設定しなければならないかどうかを示します。

アプリケーションは、CiscoMediaOpenLogicalChannelEv を受け取ったときに API をチェックする必要があり、戻り値が true の場合のみ RTP パラメータを設定します。

（注）	アーリー オファーは、リリース 8.5(1) の IPv6 コールに対してはサポートされていません。

アプリケーションが、CiscoBaseMediaTerminal.DYNAMIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT または CiscoBaseMediaTerminal.STATIC_MEDIA_REGISTRATION_FOR_GET_PORT_SUPPORT という登録タイプで、IP アドレッシング モードを IPv6 として端末を登録すると、登録は行われますが、この機能は有効にはなりません。アプリケーションは CiscoMediaOpenIPPortEv を受け取りません。

アプリケーションは、メディアの終端イベントを受け取ったとき、またはコールが切断されたときにポートを閉じます。

IPv6 のサポートが追加されると、アプリケーションはデュアル モード デバイスに対して 2 つの CiscoMediaOpenIPPortEv を受け取ります。1 つは IPv4 用で、もうひとつは IPv6 用です。コールに応答された場合、アプリケーションは、CiscoMediaOpenLogicalChannelEv の MediaIPAddressingType に基づいて、使用していないポートを閉じます。

サービス パラメータ Fail Call Over SIP Trunk if MTP Allocation Fails は、ディレイド オファーとしてコールを完了させる必要があるかどうかを判断します。ポートをサポートした状態で動的に登録されている端末について、アプリケーションが CiscoMediaOpenIPPortEv を受け取った際にアプリケーションが RTP パラメータを設定しない場合、このサービス パラメータは、Delayed Offer としてコールを完了させる必要があるかどうかを判断します。

アスタリスク（*）50 機能を使用すると、ユーザは電話機の UI から、コールを元の着信者（CiscoCall.getCalledAddress() メソッドによる戻り値）と、着信者（CiscoCall.getCurrentCalledAddress() メソッドによる戻り値）に転送できます。[即転送（iDivert）] ソフトキーを押すと、メニューに元の着信者と着信者の名前が表示されます。

ユーザがこの 2 つの名前のうちいずれかを選択すると、コールは選択した着信者のボイス メールボックスに転送されます。従来の即転送機能では、[即転送（iDivert）] ソフトキーを押すだけで、コールは元の着信者のボイス メールボックスに転送されます。Cisco Unified Communications Manager Administration は、この機能の設定のために次のサービス パラメータを導入しました。

• iDivert Legacy Behavior：ユーザが [即転送（iDivert）] ソフトキーを押したときに、電話機が、従来の即転送機能と拡張された *50 即転送機能のどちらの動作をするかを指定します。iDivert legacy サービス パラメータが true に設定されている場合は、従来の即転送の動作が適用され、false に設定されている場合は、従来の即転送機能は適用されません。

• Allow QSIG during iDivert：従来の即転送機能の使用を、QSIG トランクを越えたボイス メッセージングが統合された構成内でも許可するか、Use Legacy iDivert サービス パラメータが true に設定されている場合に限定するかを指定します。

• iDivert User Response timer：Cisco Unified Communications Manager Administration が、[即転送（iDivert）] 画面が削除される前に、ユーザからの応答を待つ時間を秒単位で指定します。この時間が経過してもユーザからの操作がない場合、タイマーは期限切れとなり、電話機から画面が削除されます。Use Legacy iDivert サービス パラメータが true に設定されている場合、Cisco Unified Communications Manager Administration はこのパラメータを無視します。

この機能では、JTAPI レイヤに対するインターフェイスの変更はありません。JTAPI アプリケーション側から見た動作の変更点は、コールが元の着信者または着信者のいずれかのボイス メールに転送される可能性があることを示します。

通常、システム管理者は JTAPI アプリケーション ユーザを設定する際に、特定の端末（Cisco Unified IP Phone およびデバイス）を各アプリケーション ユーザに関連付けます。そのため、アプリケーション ユーザが制御またはモニタできる端末は、自分に関連付けられている端末に限定されます。スーパー プロバイダー機能を使用すると、Cisco Unified Communications Manager クラスタ内のすべての端末をアプリケーションで制御したりモニタすることができます。

CiscoProvider の新しいインターフェイスである createTerminal() を使用すると、terminalName を指定して端末を作成できます。JTAPI には、インターフェイスを通じて terminalName を取得する機能が用意されていません。CiscoProvider.createTerminal(terminalName) は、端末を返します。端末がプロバイダー ドメインにすでに存在している場合、JTAPI はその既存の端末を返します。

別の新しいインターフェイスである CiscoProvider.deleteTerminal() を使用すると、CiscoProvider.createTerminal() インターフェイスで作成された CiscoTerminal オブジェクトを削除できます。端末オブジェクトが存在しない場合や、端末が CiscoProvider.createTerminal() インターフェイスで作成されたものでない場合は、JTAPI が例外をスローします。

また、JTAPI では、CiscoProviderCapabilities の新しいインターフェイスとして canObserveAnyTerminal() も提供されています。アプリケーション ユーザがこのインターフェイスを使用できるようにするには、Cisco Unified Communications Manager Administration のユーザ設定を変更します。アプリケーションはこのインターフェイスを使用して、自身に createTerminal(terminalName) インターフェイスを呼び出す能力があるかどうかを判別できます。このインターフェイスを呼び出す能力がないアプリケーションがこのインターフェイスを呼び出した場合は、JTAPI から PrivilegeViolationException がスローされます。Cisco Unified Communications Manager クラスタ内に存在しない terminalName を指定した場合は、JTAPI から InvalidArgumentException がスローされます。

このリリースの JTAPI に含まれるスーパープロバイダー関連の機能拡張では、主に次の点が変更されています。

プロバイダーがオープンされた後に Cisco Unified Communications Manager Administration で"スーパープロバイダー特権"が無効にされると、そのことが CTI 変更通知イベントを通じて JTAPI に通知され、オープンされているデバイスのうちコントロール リストにないものがすべてクリーン アップされます。

JTAPI は、"CiscoProviderCapabilityChangedEvent" を使用して変更についてアプリケーションに通知します。この新しいイベントは、フラグが変更されたときに発行され、フラグが有効化されたか無効化されたかを示します。コントロール リストにないデバイスがスーパープロバイダー モードでオープンされてコントロール リストに追加された場合、JTAPI はそのデバイスを自身のコントロール リストに追加します。

• このフラグが有効な "CiscoProviderCapabilityChangedEvent" を通常のアプリケーションが受信した場合は、スーパープロバイダー特権が付与されていることを意味しているので、このアプリケーションは自身のコントロール リストにないデバイスの取得を開始できます。

• スーパープロバイダー アプリケーションが、Superprovider フラグが無効な "CiscoProviderCapabilityChangedEvent" を受信した場合は、このアプリケーションのスーパープロバイダー特権が解除されたことを意味します。その後、次の一連のイベントが発生します。

  • Provider Out of Serivce（OOS）イベントがアプリケーションに配信され、そのアプリケーションが取得/オープンしたデバイスがすべてクローズされます。

  • 取得/オープンされたデバイスのうちコントロール リストにないすべてのデバイスについて CiscoTermRemovedEv がアプリケーションに配信されます。

  • JTAPI が通常のユーザとして CTI への再接続に成功すると、Provider inService イベントがアプリケーションに配信されます。

  • デバイスと回線の情報がアプリケーションに配信されます。

  • プロバイダーが OOS に移行する前にオープンしていたすべての制御対象デバイスについて CiscoTermCreatedEv がアプリケーションに配信されます。

• JTAPI は、"park DN monitoring" フラグが Cisco Unified Communications Manager Administration から変更されると、"CiscoProviderCapabilityChangedEvent" を使用してアプリケーションに通知します。

  • このフラグが有効なイベントを受信したアプリケーションは、パーク DN を制御するための登録機能を実行します。

  • このフラグが無効に設定されているイベントをアプリケーションが受信した場合、JTAPI は再び "CiscoProviderCapabilityChangedEvent" を使用してアプリケーションに通知し、すべてのパーク DN アドレスをクローズします。

• JTAPI は、change calling party number フラグが Cisco Unified Communications Manager Administration から変更されると、CiscoProviderCapabilityChangedEvent を使用してアプリケーションに通知します。

  • このフラグが有効なイベントを受信したアプリケーションは、発信者番号を変更できるようになります。

  • このフラグが無効なイベントを受信したアプリケーションは、発信者番号を変更できません。

  アプリケーション側でも、このフラグが無効な場合は発信者番号を変更しないようにする必要があります。

• スーパープロバイダーがコントロール リストにないデバイスをオープン/取得した後に Cisco Unified Communications Manager Administration でそのデバイスが削除された場合、JTAPI は端末オブジェクトをクローズして、そのデバイスの CiscoTermRemovedEvent をアプリケーションに送信します。

public interface CiscoProviderCapabilityChangedEv { public CiscoProviderCapabilities getCapability (); }

public boolean canModifyCallingParty(); public void setCanModifyCallingParty(boolean value);

Cisco Unified IP Phone 6901 は新しい IP フォンで、他の基本 Cisco IP フォンと似たキーパッドが使用されていますが、ディスプレイ、スピーカー フォン、ヘッド セット ジャックは付いていません。この電話機では、SCCP プロトコルだけがサポートされます。パーク、パーク解除、コール ピックアップ、グループ コール ピックアップ、直接転送、コール転送のすべての機能、参加などの機能には、ソフトキーが提供されていないため、これらの機能はサポートされません。これらの機能は、Cisco Unified Communication Manager からのみサポートされます。Cisco Unified IP Phone 6901 は 1 回線デバイスで、1 回線あたりで 2 つのコールをサポートできます。このため、回線をまたいで参加（Join Across Lines）機能および回線をまたいで直接転送（Direct Transfer Across Lines）機能は、これらのデバイスではサポートできません。

この電話機では、コールを開始または応答するには電話機がオフフックでなければならないという制限があります。電話機がオンフックの場合にコールを開始またはコールに応答すると、JTAPI は、エラー コード CiscoJtapiException.OPERATION_NOT_AVAILABLE_IN_CURRENT_STATE でアプリケーションに InvalidStateException をスローします。

また、Cisco Unified IP Phone 6901 には、アプリケーションから XSI オブジェクトを受信しないという制限もあります。アプリケーションがこれらの電話機に対して sendData() API を呼び出すと、JTAPI は、エラー コード CiscoJtapiException.COMMAND_NOT_IMPLEMENTED_ON_DEVICE で、アプリケーションに対する要求に例外をスローします。

この機能により、Cisco Unified JTAPI アプリケーションは、ロールオーバー モードを有効にして端末を制御できます。ロールオーバー モードでは、同じ DN だが異なるパーティション内の、または異なる DN の複数のアドレスで端末を設定できます。ロールオーバー モードを有効にすると、端末で次に使用可能なアドレスでコンサルト コールを作成できます。Cisco Unified IP Phone 6900 シリーズはロールオーバー モードで設定できます。

ロールオーバー モードをサポートしている電話の新しい権限 Standard CTI Allow Control も導入されており、アプリケーションでロールオーバーが有効にされた端末を制御できます。この新しい動作をサポートするアプリケーションは、コンサルト コールが異なるアドレスで作成される場合に、それらのアプリケーションまたはエンド ユーザにこの権限を含める必要があります。そうしないと、ロールオーバー モードで設定されたすべての端末が制限され、addObserver() 要求に例外がスローされます。

この動作をサポートするアプリケーションは、端末にコール オブザーバを追加するか、端末上のすべてのアドレスにコール オブザーバを追加する必要があります。コンサルト コールは次に使用可能なアドレスで作成されるため、すべてのアドレスにコール オブザーバが追加されていない場合、コンサルト要求に例外がスローされます。

アプリケーションから会議を正常に実行するために、Cisco Unified IP Phone 6900 シリーズで回線をまたいで参加（Join Across Lines）が有効にされている必要があります。

Cisco Unified Communications Manager Release 8.6 では、JTAPI は Cisco Unified IP Phone 69xx シリーズでの回線あたり複数コール設定をサポートしています。リリース 8.6 以前、Cisco Unified IP Phone 69xx シリーズは 1 回線に 1 コールしかサポートしていませんでした。1 回線に定義されるコール最大数/ビジー トリガー（MNC/BT）に 2/1 を超える値は設定できませんでした。回線あたり複数コールが可能な Cisco Unified IP Phone 69xx シリーズでは、回線あたり複数のコールをサポートし、MNC/BT は 2/1 より大きな値に設定されます。

この機能を使用すると、ユーザは、100 を超える電話番号をデバイス（電話機、CTI ポートおよびルート ポイント）に関連付けることができます。JTAPI では、この機能がサポートされ、端末上の対応するアドレスがアプリケーションに対して表示されます。

この機能により、Cisco Unified JTAPI で、サポートされる IP フォンでのスワップおよびキャンセル操作をサポートできます。

スワップ操作を呼び出すと、アクティブなコールが保留になり、保留したコールが取得されます。キャンセル操作を呼び出すと、プライマリ コールとコンサルト コール間のコンサルト関係が破棄されます。これらの操作はサポートされる電話だけから呼び出すことができます。Cisco Unified JTAPI インターフェイスでは、アプリケーションから、スワップ/キャンセル操作を呼び出すことができません。ユーザが電話の [切替（SWAP）] キーを押すと、JTAPI が保留されているアクティブなコールに CallCtlTermConnHeldEv および CallCtlTermConnTalkingEv を配信し、CiscoFeatureReason.REASON_NORMAL でそれらの状態変更を示します。

キャンセル操作が呼び出され、プライマリ コールとコンサルト コールの関係が破棄されても、Cisco Unified JTAPI は直接転送または参加機能を使用して、転送や会議操作を実行できます。コンサルトの開始後に、ユーザが電話の [キャンセル（CANCEL）] キーを押した場合、会議や転送は実行されません。電話の [キャンセル（CANCEL）] キーを押すと、アプリケーションへのキャンセル通知がトリガーされます。Cisco Unified JTAPI によって、キャンセル操作を示す CiscoCallFeatureCancelledEv が送信されます。CiscoCallFeatureCancelledEv.getConsultCall() は以前に作成されたコンサルト コールを返します。

接続転送または会議中にキャンセル操作が実行されると、次のことが発生する可能性があります。

• ユーザが [アクティブ コール（Active Call）] ソフトキーを選択する前に、[キャンセル（CANCEL）] キーを押す。

  この場合、[転送（Transfer）] キーを押すと、consultCall GC3 が作成され、[キャンセル（CANCEL）] キーを押すと、コンサルト コールとして GC2 と GC3 で CiscoCallFeatureCancelledEv がトリガーされます。

• [アクティブ コール（Active Call）] ソフトキーを押した後、ただし電話 UI でコールを選択する前に、ユーザが [キャンセル（CANCEL）] キーを押す。

  この場合、電話 UI で [アクティブ コール（Active Call）] ソフトキーを押すと、consultCall GC3 が IDLE になりますが、他の機能の操作が可能であるため、CANCEL 通知はありません。ただし、ユーザが [キャンセル（CANCEL）] キーを押した場合、コンサルト コールを Null として CiscoCallConsultCancelEv がトリガーされます。

• ユーザが [アクティブ コール（Active Call）] ソフトキーを押し、コールを選択して、[キャンセル（CANCEL）] を押す。

  この場合、選択したコールは、CiscoCallFeatureCancelledEv で consultCall として返されます。

この機能により、アドレスと端末で異なる設定を公開するインターフェイスを利用できるようになりました。端末またはアドレスがアウトオブサービス状態のときでも、これらのインターフェイスを呼び出すことができます。すべてのインターフェイスは、Cisco Unified Communications Manager で設定され、登録されている値を返します。端末が登録されていない場合、InvalidStateException が返されます。ボイス メール パイロットのみは、端末が登録されていない場合でも、アプリケーションから取得できます。

ボイス メールを除くあらゆる変更に対し、端末をリセットして新しい値を有効にする必要があります。リセット後に電話機を再登録した後に限り、インターフェイスは新しい値を返します。アプリケーションではインターフェイス CiscoProvTerminalRegisteredEv を使用して、端末とアドレスの設定を読み取ることができます。

CiscoAddress では、次の設定ができます。

• 設定されているコール最大数

• ビジー トリガー

• 端末でのアドレスの位置

• ボイス メール パイロット

• ASCII ラベルと Unicode ラベル

CiscoTerminal は、アプリケーションで端末の次の設定を取得するための新しいインターフェイスを提供します。

• IPV4 および IPV6 IP アドレス

• アウトバウンド ロールオーバー設定

端末とアドレス機能によって、端末が次の機能を実行できるかどうかを判断するための新しいインターフェイスを利用できるようになりました。

• コンサルト コールのロールオーバー

• アウトバウンド コールのロールオーバー

• 回線をまたいで参加

• 回線をまたいで直接転送

• 同じ回線で参加

• 同じ回線で直接転送

この機能拡張では、管理者が Cisco Unified Communications Manager Administration の制限リストに特定の端末とアドレスのセットを追加した場合、それらの端末とアドレスをアプリケーションで制御またはモニタすることが制限されます。

管理者はデバイス上の特定の回線（特定の端末上のアドレス）を制限リストに追加できます。Cisco Unified Communications Manager Administration の制限リストに端末を追加した場合は、JTAPI でもその端末のすべてのアドレスが制限付きとしてマークされます。この設定が完了した後にアプリケーションを起動した場合は、CiscoTerminal.isRestricted() インターフェイスと CiscoAddress.isRestricted(Terminal) インターフェイスを確認することで、特定の端末またはアドレスが制限されているかどうかを知ることができます。共用回線の場合は、CiscoAddress.getRestrictedAddrTerminals() インターフェイスを照会することで、特定のアドレスがいずれかの端末で制限されているかどうかを確認できます。

アプリケーションの起動後に回線（端末上のアドレス）が制限リストに追加された場合は、CiscoAddrRestrictedEv がアプリケーションに送信されます。そのアドレスにオブザーバがある場合は CiscoAddrOutOfService がアプリケーションに送信されます。制限リストから回線が削除されると、CiscoAddrActivatedEv がアプリケーションに送信されます。そのアドレスにオブザーバがある場合は CiscoAddrInServiceEv がアプリケーションに送信されます。アプリケーションが制限リストに含まれるアドレスにオブザーバを追加しようとすると、PlatformException がスローされます。アドレスが制限される前に追加されたオブザーバはそのまま残りますが、そのアドレスが制限リストから削除されない限り、これらのオブザーバでイベントを取得できません。アプリケーションからアドレスのオブザーバを削除することもできます。

アプリケーションの起動後にデバイス（端末）が制限リストに追加された場合は、CiscoTermRestrictedEv がアプリケーションに送信されます。その端末にオブザーバがある場合は CiscoTermOutOfService がアプリケーションに送信されます。端末が制限リストに追加されると、JTAPI でもその端末に属するすべてのアドレスが制限され、CiscoAddrRestrictedEv がアプリケーションに送信されます。制限リストから端末が削除されると、CiscoTermActivatedEv と、対応するアドレスの CiscoAddrActivatedEv がアプリケーションに送信されます。アプリケーションが制限リストに含まれる端末にオブザーバを追加しようとすると、PlatformException がスローされます。端末が制限される前に追加されたオブザーバはそのまま残りますが、その端末が制限リストから削除されない限り、これらのオブザーバでイベントを取得することはできません。

アプリケーションの起動後に共用回線が制限リストに追加された場合は、CiscoAddrRestrictedOnTerminalEv がアプリケーションに送信されます。そのアドレスにアドレス オブザーバがある場合は、その端末の CiscoAddrOutOfServiceEv がアプリケーションに送信されます。すべての共用回線が制限リストに追加された場合は、最後の 1 つが追加された時点で、CiscoAddrRestrictedEv がアプリケーションに送信されます。アプリケーションの起動後に制限リストから共用回線が削除された場合は、CiscoAddrActivatedOnTerminalEv がアプリケーションに送信されます。そのアドレスにオブザーバがある場合は、その端末の CiscoAddrInServiceEv がアプリケーションに送信されます。コントロール リストに含まれるすべての共用回線が制限リストから削除された場合は、最後の 1 つが削除された時点でアプリケーションに CiscoAddrActivatedEv が送信され、端末上のすべてのアドレスが InService イベントを受信します。

コントロール リストに含まれるすべての共用回線が制限リストに追加されている場合、アプリケーションがオブザーバを追加しようとすると、PlatformException がスローされます。一部の共用回線だけが制限リストに追加されている場合、アプリケーションがそのアドレスにオブザーバを追加すると、制限されていない回線だけがイン サービスになります。

アドレスまたは端末が制限リストに追加されてリセットされたときにアクティブ コールが存在していた場合は、Connection と TerminalConnections が接続解除されます。

アドレスと端末が制限リストに 1 つも追加されていない場合、この機能は JTAPI の以前のバージョンと下位互換性を持ち、新しいイベントはアプリケーションに配信されません。

次のセクションでは、アドレスおよび端末の制限に関するインターフェイスの変更点について説明します。

public interface CiscoRestrictedEv extends CiscoProvEv {
 public static final int ID  =  com.cisco.jtapi.CiscoEventID.CiscoRestrictedEv;

 /**
  * The following define the cause codes for restricted events
  */

public final static int CAUSE_USER_RESTRICTED  =  1;

public final static int CAUSE_UNSUPPORTED_PROTOCOL  =  2;

}

転送機能では、1 つのコール（転送コール）の参加者が別のコール（最終コール）に転送されます。コールの参加者を移動すると、コール転送に関連付けられた Connection が DISCONNECTED 状態に移行し、これらの参加者の新しい Connection が最終コールに作成されます。同様に、転送コールに関連するすべての TerminalConnection が Dropped 状態に移行し、最終コール内に作成されます。Cisco の拡張機能では、定義で、転送に関連するイベントの開始と終了をマークします。

CiscoConnection.getConnectionID() メソッドを使用して、新旧の Connection に関する CiscoConnectionID を取得することで、新たに作成された Connection オブジェクトと古い Connection オブジェクトを関係付けることができます。Connection が一致する場合は、CiscoConnectionID.equals() メソッドを使用して比較したときに CiscoConnectionID オブジェクトが一致します。