- はじめに
- 概要
- 新機能と変更情報
- Cisco Unified JTAPI でサポートされる機能
- Cisco Unified JTAPI のインストール
- Cisco Unified JTAPI パッケージのすべての 階層
- Cisco Unified JTAPI 拡張
- Cisco Unified JTAPI のアラームとサービス
- Cisco Unified JTAPI の例
- メッセージ シーケンスの図
- Cisco Unified JTAPI クラスおよびインター フェイス
- Cisco Unified JTAPI のトラブルシューティ ング
- リリースごとの Cisco Unified JTAPI オペ レーション
- CTI でサポートされる デバイス
- 定数フィールド値
- 非推奨の API
- 索引
Cisco Unified JTAPI 開発者ガイド for Cisco Unified Communications Manager リリース 7.1(2)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月14日
章のタイトル： メッセージ シーケンスの図
- 共用回線のサポート
- 転送と直接転送
- 会議と参加
- 割り込みとプライバシー
- CallSelect と UnSelect
- コールごとの CTIPort 動的登録
- ルート ポイントでのメディア終端
- リダイレクト時のオリジナルの着信者番号
- シングル ステップ転送
- 発信側番号の変更
- Forced Authorization Code と Customer Matter Code
- スーパー プロバイダーのメッセージ フロー
- QSIG パス置換
- デバイス ステート サーバ
- パーティションのサポート
- ヘアピン サポート
- QoS のサポート
- TLS セキュリティ
- SRTP 鍵情報
- デバイスと回線の制限
- SIP のサポート
- SIP REPLACE
- Unicode のサポート
- 下位互換性に関する機能拡張
- 半二重メディア
- 録音と監視
- インターコム
- Do Not Disturb（サイレント）
- セキュア会議
- JTAPI Cisco Unified IP 7931G Phone の対話
- ロケール インフラストラクチャ変更シナリオ
- 発信側の正規化
- クリック ツー会議
- コール ピックアップ
- コーリングサーチスペースおよび機能プライオリティを使用した selectRoute()
- エクステンション モビリティ ログイン ユーザ名
- 発信側の IP アドレス
- CiscoJtapiProperties
- IPv6 のサポート
- 回線をまたいで直接転送（Direct Transfer Across Lines）の使用例
- Connected Conference または回線をまたいで参加（Join Across Lines）の使用例：新しい電話の動作
- 拡張された MWI の使用例
- 回線をまたいで参加（Join Across Lines）の拡張機能
- スワップ/キャンセルおよび転送/会議の動作変更
- 任意の通話者のドロップ（Drop Any Party）の使用例
- パーク モニタリング サポート
- 使用例 1：パーク モニタリングの状態
- 使用例 2: 共用回線シナリオ：Cisco Unified IP Phone でパークする
- 使用例 3：共用回線シナリオ：Cisco Unified IP Phone 7900 Series with SIP でパークする
- 使用例 4: スナップ ショット シナリオの使用例
- 使用例 5：パーク DN が監視されている
- 使用例 6：パークされているコールのクエリ番号
- 使用例 7：フィルタの有効化または無効化
- 使用例 8：フィルタの有効化または無効化
- 使用例 9：フィルタの有効化または無効化
- 使用例 10：フィルタの有効化または無効化
- パーク モニタリングのその他の使用例
- DPark 関連の使用例
- 論理パーティション設定機能の使用例
- ComponentUpdater 拡張の使用例
- IPv6 のサポート
- Cisco Unified IP Phone 6900 シリーズのサポート
メッセージ シーケンスの図
この付録には、次のシナリオに関するメッセージ フローを示すメッセージ シーケンスの図があります。
•
転送と直接転送
• 会議と参加
• 発信側番号の変更
• CTIPort および RoutePoint での AutoAccept
• Forced Authorization Code と Customer Matter Code
• SRTP 鍵情報
• 半二重メディア
• 録音と監視
• インターコム
• DND-R
• セキュア会議
• JTAPI Cisco Unified IP 7931G Phone の対話
• 発信側の正規化
• コーリングサーチスペースおよび機能プライオリティを使用した selectRoute()
• Connected Conference または回線をまたいで参加（Join Across Lines）の使用例：新しい電話の動作
• 回線をまたいで参加（Join Across Lines）の拡張機能
共用回線のサポート
共用回線のサポートに関するメッセージ フローを次に示します。
AddressInService/AddressOutofService イベント
共用アドレスへの着信コール
共用アドレスからの発信コール
共用アドレス自体へのコール
転送と直接転送
直接転送/任意転送のシナリオ
直接転送/任意転送のシナリオ：ページ 2
コンサルト転送
会議と参加
参加/任意会議
コンサルト会議
拡張された回線をまたいで参加（Join Across Lines）
拡張された回線をまたいで参加（Join Across Lines）メッセージ フローを次の表に説明しています。A、C、D、E、および F は異なる端末のアドレスです。B1 と B2 は同じ端末 TermB のアドレスです。
割り込みとプライバシー
割り込みとプライバシーに関するメッセージ フローを次に示します。
割り込み
C 割込
プライバシー
CallSelect と UnSelect
CallSelect と UnSelect に関するメッセージ フローを次に示します。
コールごとの CTIPort 動的登録
コールごとの CTIPort 動的登録に関するメッセージ フローを次に示します。
ルート ポイントでのメディア終端
ルート ポイントでのメディア終端に関するメッセージ フローを次に示します。
リダイレクト時のオリジナルの着信者番号
次のシナリオは、リダイレクト時におけるオリジナルの着信者番号に関するメッセージ フローを示しています。
• A、B、C がアプリケーション コントロール リストにある。
• B は、C を preferredOriginalCalledParty として D にコールをリダイレクトする。
アプリケーションには、A と B について次のイベントが示されます。
（注） クラスタ内の通話者の場所、負荷、その他の条件によっては、指定されたイベント グループが同じ順序になく、変更される場合があります。
• B は、C を preferredOriginalCalledParty として D にコールをリダイレクトする。
アプリケーションには、D について次のイベントが示されます。
シングル ステップ転送
アドレス A、B、および C がコントロール リストにあり、B を転送コントローラとして A と B の間のコールが C へ転送されます。アプリケーションには次のイベントが示されます。
発信側番号の変更
次のシナリオは、発信側番号の変更に関するメッセージ フローを示しています。
アプリケーションが、デバイスの Route Point（RP）を制御し、RP を登録する。
A と B は PNO で、Cisco Unified Communications Manager クラスタ内にある。
A から RP へのコールにより、発信側番号が M に変更されたコールが B へ selectRoute 処理される。
CTIPort および RoutePoint での AutoAccept
Forced Authorization Code と Customer Matter Code
アプリケーションが A と B を制御していて、B にコールを発信するには Forced Authorization Code（FAC）が必要です。
アプリケーションが A と B を制御していて、B にコールを発信するには FAC および CMC の両方が必要です。
B は CMC を必要としており、アプリケーションが無効なコードを入力します。
アプリケーションが A と B の両方を制御していて、A が B にコールし、B が、FAC および CMC の両方を必要とする C にコールをリダイレクトします。
アプリケーションが、デバイスの Route Point（RP）を制御し、RP を登録します。
A と B は PNO で、Cisco Unified Communications Manager クラスタ内にあります。
スーパー プロバイダーのメッセージ フロー
アプリケーションが、アドレス 2000 および 2001 を持つ CTIPort1 の端末の作成を試みます。次のイベントがアプリケーションに送信されます。
スーパープロバイダーと変更通知の拡張の使用例
新しいフェールオーバー シナリオと変更通知を処理するためにアプリケーションに送信される新しいイベントが JTAPI に追加されました。これによりフェールオーバー シナリオの処理や、スーパープロバイダー モードと通常ユーザ モードの切り替えにかかる時間の処理について JTAPI が拡張されます。
スーパープロバイダー ユーザが、プロバイダーをオープンして、コントロール リストにないいくつかのデバイスをスーパープロバイダー モードでオープンします。admin ページから Superprovider 特権を解除します。
アプリケーションは CiscoProviderCapabilityChangedEvent イベントを受け取ります。JTAPI から、オープンまたは取得したデバイスのうちコントロール リストにないものすべてについて、CiscoTermRemovedEv が送信されます。JTAPI はアプリケーションにプロバイダー OOS を送信し、コントロール リストに含まれないデバイスに CiscoTermRemovedEv を送信して、CTI への接続を再オープンします。接続が成功すると、JTAPI はプロバイダーのイン サービス イベントをアプリケーションに送信します。そうでない場合は、プロバイダーをクローズします。
通常ユーザが、プロバイダーをオープンして、コントロール リストにあるいくつかのデバイスをオープンします。admin ページから Superprovider 特権をユーザに追加します。
アプリケーションは CiscoProviderCapabilityChangedEvent イベントを受け取ります。ユーザはコントロール リストにないデバイスを取得またはオープンできるようになります。
通常ユーザが、プロバイダーをオープンして、いくつかのパーク DN をオープンします。admin ページからユーザのパーク DN のモニタ特権を解除します。
アプリケーションは CiscoProviderCapabilityChangedEvent イベントを受け取ります。JTAPI はすべてのパーク DN アドレスをクリーンアップします。
通常ユーザがプロバイダーをオープンします。admin ページからユーザにパーク DN のモニタ特権を追加します。
アプリケーションは CiscoProviderCapabilityChangedEvent イベントを受け取ります。アプリケーションはパーク DN のモニタリング機能を登録し、パーク DN のモニタリングを実行できるようになります。
通常ユーザがプロバイダーをオープンします。admin ページからユーザの「modify calling party」特権を解除します。
アプリケーションは CiscoProviderCapabilityChangedEvent イベントを受け取ります。アプリケーションは、リダイレクト中に発番号を変更できません。これを実行しようとすると、JTAPI がエラーをスローします。
通常ユーザがプロバイダーをオープンします。admin ページからユーザに「modify calling party」特権を追加します。
アプリケーションは CiscoProviderCapabilityChangedEvent イベントを受け取ります。アプリケーションは、リダイレクト中に発番号を変更できます。
スーパープロバイダー ユーザが、プロバイダーをオープンして、コントロール リストにないデバイスを取得します。admin ページからデバイスを削除します。
アプリケーションは CiscoTermRemovedEv イベントを受け取ります。デバイスは JTAPI の観点からクローズされます。
QSIG パス置換
次の表は、Q.Signaling（QSIG）トランクで接続された PBX 間のコールが転送されたときに、アプリケーションに送信される JTAPI イベントを示しています。また、QSIG パス置換機能によってリアルタイム パス（RTP）が最適化されたときにアプリケーションに送信されるイベントも示しています。
トランスレーション パターンによってパターンが変更されている場合、QSIG トランクを介するコールには遠端との接続がないことがあります。つまり、アプリケーションでトロンボーン ケースのコールが 2 つ確認されているときに、B がそれらのコールの共通の接続として機能するとは限りません。
デバイス ステート サーバ
パーティションのサポート
JTAPI のアドレスのハッシュ機構が変更されたため、この機能によるアドレス検索やロード テスト時のパフォーマンスは低下することが予想されます。
getPartition() API の使用
次の例は、JTAPI およびアプリケーションで getPartition() を使用して DN が同じでパーティションが異なるアドレスを区別する方法を示したものです。
ここでは、3 つの異なるパーティションに属する A（2001, P1）、B（2001, P2）、および C（2001, P3）という 3 つのアドレスがあるとします。2001 は DN を表し、P1、P2、および P3 はそれぞれのパーティションを表します。
JTAPI が provider.getAddress("2001") をコールすると、プロバイダー オブジェクトは A、B、および C の 3 つのアドレス オブジェクトを含む配列を返します。これはこの 3 つがすべて同じ DN を持っているためです。
アプリケーションおよび JTAPI は、アドレス オブジェクトの getPartition() メソッドを使用して 3 つのアドレスを区別します。
getAddress(String number, String partition) の使用
次の例は、DN が同じでパーティションが異なる複数のアドレスがある場合に、JTAPI が getAddress(String number, String partition) API を使用して特定の DN およびパーティションに対応するアドレス オブジェクトを取得する方法を示しています。
例 A-2 getAddress(String number, String partition) の使用
この例では、3 つの異なるパーティションに属する 3 つのアドレスがあります。それぞれ A（2001, P1）、B（2001, P2）、および C（2001, P3）と表します。2001 は DN を表し、P1、P2、P3 はそれぞれのパーティションを表します。
JTAPI が provider.getAddress("2001", "P1") をコールすると、プロバイダー オブジェクトは API で指定したのと同じ DN（2001）とパーティション情報（P1）を持つアドレス オブジェクトを返します。この場合、アプリケーションにはアドレス オブジェクト A が返されます。
A が B にコールするシナリオを考えます。A は DN が 1000 であり、同じく DN が 1000 である B にコールします。A はパーティション P1 に属し、B はパーティション P2 に属します。次の図は、このシナリオにおけるさまざまなイベントおよび API コールの結果を示しています。これはパーティション サポート機能に関連するものです。
パーク DN
JTAPI ではパーク DN もアドレスとして扱われます。そのため、パーク DN も通常の DN と同様に処理されます。次のメッセージ フローは、パーク DN が使用されているコールでアプリケーションがパーク DN のパーティション情報を使用する方法を示したものです。
アプリケーションがパーク DN をモニタリングする際、パーク DN は通常の DN と同じものにできます（それぞれが異なるパーティションに属している場合）。
このケースでは、C は A および B と同じ DN 値を持つパーク DN であり、異なるパーティションに属しています。
A がコールを受信してそれを C にパークします。B がそのコールをパーク解除します。コールがパークおよびパーク解除されると、CiscoProvCallParkEv が生成されます。API
getParkingPartyPartition()、getParkedPartyPartition()、および getParkPartyPartition() は、図に示したような関連するアドレス オブジェクトを返します。
パーティションの変更
パーティションのアトリビュートは、アドレスの DN アトリビュートと同様のものです。そのためパーティションのアトリビュートを変更するたび、アドレス オブジェクトを破棄して作成し直す必要があります。アドレスのパーティション情報を変更すると、JTAPI が再起動され、その際に現在のアドレス オブジェクトが削除されて、パーティション情報の変更を反映した新しいアドレス オブジェクトが作成されます。
アドレスのパーティション情報を変更すると、アドレス オブジェクトは破棄されて、新しいアドレス オブジェクトが作成されます。
新しいアドレス オブジェクトには新しいパーティション情報が格納されます。
上の例では、アドレス A のパーティション文字列が P4 に変更されています。そのため A の現在のアドレス オブジェクトは削除されて、新しいアドレス オブジェクトが作成されます。
A.getPartition() を使用して古いアドレス オブジェクトを問い合せると「P1」が返され、同じ問い合せを新しいオブジェクトに対して行うと「P4」が返されます。
アドレスのパーティションが変更されたら、アプリケーションはアドレス オブジェクトの問い合せを行ってパーティション情報を更新する必要があります。
JTAPI のパーティションのサポート
次のすべての使用例では、JTAPI がオープンするすべての回線のパーティション情報を CTI が応答メッセージで提供し、JTAPI は保持する全アドレスのパーティション情報を保管していることを想定しています。
ヘアピン サポート
QoS のサポート
JTAPI QoS
QoS を Windows で機能させるには、次の手順を完了する必要があります。
ステップ 1 レジストリ エディタ（Regedt32.exe）を起動します。
HKEY_LOCAL_ MACHINE¥System¥CurrentControlSet¥Services¥Tcpip¥Parameters¥
ステップ 3 [編集] メニューで、[値の追加] をクリックします。
ステップ 4 DisableUserTOSSetting と入力します。
ステップ 5 [データ型] ボックスの [REG_DWORD] をクリックします。
詳細については、 http://support.microsoft.com/default.aspx?scid=kb;ja-jp;248611 を参照してください。
TLS セキュリティ
証明書を更新して TLS 認証を確立するためのメッセージ フローを、図 A-2 および 図 A-3 に示します。
図 A-3 CTI/API のセキュリティ アプローチ（続き）
SRTP 鍵情報
この機能を有効にした場合、Cisco Unified JTAPI のパフォーマンスが低下することが予想されます。このパフォーマンス低下は、CTI と JTAPI の間での暗号化シグナリング、およびエンド ポイント間での暗号化メディアによるものです。
デバイスと回線の制限
SIP のサポート
SIP REPLACE
次に説明する各シナリオの JTAPI イベントでは、Terminal イベントは示していません。Terminal イベントは、監視されているすべての Terminal に通常どおり送信されます。またイベントは、A、B、または C のいずれかだけが監視されるという前提で示されています。A、B、C が組み合わせて監視されている場合はイベントが変わります。
SIP REFER
次のセクションでは、SIP REFER の実行時に発生する可能性があるシナリオを説明します。REFER シナリオには、IN-Dialog および OutOfDialog の 2 つのカテゴリがあります。
IN-Dialog REFER シナリオ
次の IN-Dialog REFER に関する各セクションでは、11 のシナリオ（A ～ K）を説明します。
A（クラスタ内または制御内の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C が呼び出し中になる。
JTAPI が A の Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection を「UNKNOWN」状態にする。
提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。
C には、新しい Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection が作成される。
B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
B を監視している JTAPI アプリケーションに示される内容：
C を監視している JTAPI アプリケーションに示される内容：
A（クラスタ内または制御内の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C がコールに応答する。
JTAPI は A の Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection を接続解除またはドロップする。提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。
C では、Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection が、Connected/Established/Active/Talking 状態に移行する。
B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
B を監視している JTAPI アプリケーションに示される内容：
C を監視している JTAPI アプリケーションに示される内容：
A（クラスタ内の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C が呼び出し中になるが、C はコールに応答せず、転送設定も行われていない。参照は失敗し、A と B 間の元のコールが再開される。
JTAPI は C の Connection/CallControlConnection/TerminalConnection/
CallControlTerminalConnection を接続解除またはドロップする。提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供し、A の Connection/CallControlConnection/
TerminalConnection/CallControlTerminalConnection を「Unknown」状態から
Connected/Established/Active/Talking 状態に移行させる。
A: Cgpn=A, Cdpn=B, Lrp= OCdpn=B
B: Cgpn=A, Cdpn=B, Lrp= OCdpn=B
A を監視している JTAPI アプリケーションに示される内容：
B を監視している JTAPI アプリケーションに示される内容：
A（クラスタ外の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C が呼び出し中になる。
JTAPI は C の Connection/CallControlConnection/TerminalConnection/
CallControlTerminalConnection を作成し、B で CPIC を取得する際に A の Connection/CallControlConnection をドロップする。提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。
B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
B を監視している JTAPI アプリケーションに示される内容：
C を監視している JTAPI アプリケーションに示される内容：
A（クラスタ外の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C が呼び出し中になるが、C はコールに応答せず、転送設定も行われていない。参照は失敗し、A と B 間の元のコールが再開される。
JTAPI は再度 A の Connection/CallControlConnection を作成し、C の Connection/
CallControlConnection/TerminalConnection/CallControlTerminalConnection をドロップする。
提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。
A: Cgpn=A, Cdpn=B, Lrp= OCdpn=B
B: Cgpn=A, Cdpn=B, Lrp= OCdpn=B
A を監視している JTAPI アプリケーションに示される内容：
C を監視している JTAPI アプリケーションに示される内容：
A（クラスタ内または制御内の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C がコールに応答する。
JTAPI は C の Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection を、Connected/Established/Active/Talking 状態に移行させる。提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。
B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
B を監視している JTAPI アプリケーションに示される内容：
C を監視している JTAPI アプリケーションに示される内容：
A（クラスタ内または制御内の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C は D への forwardAll を実行して、D が呼び出し中になる。
JTAPI は D の Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection を作成する。提供される CAUSE_CODE は CAUSE_REDIRECT で、CTI から受信される原因は ForwardAll になる。
B: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C
D: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C
B を監視している JTAPI アプリケーションに示される内容：
D を監視している JTAPI アプリケーションに示される内容：
A（クラスタ内または制御内の SIP UA）は B とのコール中。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C は D へのリダイレクトを実行し、D が呼び出し中になる。
JTAPI は D の Connection/CallControlConnection/TerminalConnection/CallControlTerminalConnection を作成する。提供される CAUSE_CODE は CAUSE_REDIRECT で、D の NewCallEvent で CTI から受信される原因は Redirect になる。
B: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
C: Cgpn=B, Cdpn=C, Lrp=A OCdpn=C
B: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C
D: Cgpn=B, Cdpn=D, Lrp=C OCdpn=C
B を監視している JTAPI アプリケーションに最後のコールで示される内容：
D を監視している JTAPI アプリケーションに示される内容：
A（クラスタ内または制御内の SIP UA）は B とのコール中。
B が D へのコンサルト転送を行い、A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C が呼び出し中になって、B による転送が成立する。C の呼び出し中は、転送が失敗する。
A（クラスタ内または制御内の SIP UA）は B とのコール中。
B が D へのコンサルト転送を行い、A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C がコールに応答する。
参照が成功する。B が転送を実行し、転送は成功して C と D がコール中になる。
JTAPI は A の Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection を接続解除またはドロップする。提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。
C では、Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection が、Connected/Established/Active/Talking 状態に移行する。
D: Cgpn= C, Cdpn=D, Lrp=B OCdpn=D
C: Cgpn=C, Cdpn=D, Lrp=B OCdpn=D
D を監視している JTAPI アプリケーションに示される内容：
C を監視している JTAPI アプリケーションに示される内容：
B は D とのコール中。B は A（クラスタ内または制御内の SIP UA）にコンサルト コールする。
A（Referrer）が B（Referee）に C（Refer To Target）を参照させ、C が呼び出し中になって、B による転送が成立する。
REFER は失敗する。A のコールはドロップされ、転送が成功し、D は RingBack を受け取って、C が呼び出し中になる。
JTAPI は A の Connect/CallControlConnection/TerminalConnection/
CallControlTerminalConnection を接続解除またはドロップする。提供される CAUSE_CODE は CAUSE_NORMAL で、新しい API が REASON_REFER を提供する。アプリケーションには、REFER が失敗したかどうかは知らされない。
C では、Connect/CallControlConnection/TerminalConnection/CallControlTerminalConnection が、Alerting/Alerting/Ringing/Ringing 状態に移行する。
D: Cgpn= D, Cdpn=C, Lrp=B OCdpn=C
C: Cgpn=D, Cdpn=C, Lrp=B OCdpn=C
D を監視している JTAPI アプリケーションに示される内容：
OutOfDialog Refer
SIP-UA A が B（Referee）に C（Refer To Target）を参照させる。
B は Cgpn=A、Cdpn=B、Lrp=、OCdpn=B の newcall を受け取る。
JTAPI アプリケーションは B に作成された CallActive、Connection、CallCtlConnection、TerminalConnecton、および CallCtlTerminalConnection を CAUSE_NORMAL とともに受信し、新しい API が REASON_REFER を返す。
B の Connection/CallCtlConnection および TerminalConnection/CallCtlTerminalConnection は、Connected/Established/Active/Talking 状態に移行する。JTAPI は、CTI/CP に提供された FarEndPointType_ServerCall に基づいて、A に「UNKNOWN」状態の Connection および CallCtlConnection を作成する。
B がコールに応答し、A との接続が確立される（この段階では RTP イベントは送信されない）。
B が、Cgpn=B、Cdpn=C、Lrp=A、OCdpn=C、Reason=REFER の CallPartyInfoChangedEv を受信する。
C が、Cgpn=B、Cdpn=C、Lrp=A、OCdpn=C、Reason=REFER を提供する NewCall を受信する。
JTAPI アプリケーションは B に作成された Connection、CallControlConnection、TerminalConnecton、および CallCtlTerminalConnection を CAUSE_NORMAL とともに受信し、新しい API が REASON_REFER を返す。
C がコールを受け入れるか応答し、B が C と接続される（これでアプリケーションが RTP イベントを受信する）。
C の Connection/CallCtlConnection および TerminalConnection/CallCtlTerminalConnection は、Connected/Established/Active/Talking 状態に移行する。
B を監視している JTAPI アプリケーションに示される内容：
SIP 3XX リダイレクション
3XX リダイレクション：302 Moved Temporarily
JTAPI アプリケーションが 1000@ccm.cisco.com を監視している。
Cisco Unified Communications Manager の user1000 が、 333555@aaa.com へのコールを開始する。
CTI が INVITE に基づいて NewCallNotify および CtiCallStateNotify（Dialtone/Dialing）を報告する。
JTAPI が、CallActiveEv、および 1000 の Connection イベントと CallCtlConnection イベントを報告する。
JTAPI が CallCtlConnEstablishedEv を報告する。
SIP プロキシが 333555@aaa.com の 302 を報告する。302 に基づいて、Cisco Unified Communications Manager が 333777@bbb.com への q 値に基づくターゲット リストに含まれる最初の接点へのコールを開始する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
JTAPI が 333777@bbb.com への接続作成イベントを報告する。
CTI が CtiCallStateNotify（Ringback）および CtiCallStateNotify（Connected）を報告する。
JTAPI が遠端の ConnAlertingEv および ConnEstablishedEv を報告する。
JTAPI CTI アプリケーションが 1000@ccm.cisco.com を監視している。
Cisco Unified Communications Manager の user1000 が、 333555@aaa.com へのコールを開始する。
CTI が INVITE に基づいて NewCallNotify および CtiCallStateNotify（Dialtone/Dialing）を報告する。
JTAPI が、CallActiveEv、および 1000 の Connection イベントと CallCtlConnection イベントを報告する。
CTI が CtiCallStateNotify（Proceeding）を報告する。
JTAPI が CallCtlConnEstablishedEv を報告する。
SIP プロキシが 333555@aaa.com の 302 を報告する。302 に基づいて、Cisco Unified Communications Manager が 333777@bbb.com への q 値に基づくターゲット リストに含まれる最初の接点へのコールを開始する。
333777@bbb.com から、486 ユーザ ビジー応答が報告される。この応答に基づいて、Cisco Unified Communications Manager が 555888@cisco.com へのコールを開始する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
JTAPI が 555888@cisco.com への接続作成イベントを報告する。
CTI が、CtiCallStateNotify（Ringback）および CtiCallStateNotify（Connected）も報告する。
JTAPI が新しい通話者の CallCtlConnAlertingEv および CallCtlConnEstablishedEv を報告する。
3XX リダイレクション：Contact Does Not Answer
JTAPI アプリケーションが 1000@ccm.cisco.com を監視している。
Cisco Unified Communications Manager の user1000 が、 333555@aaa.com へのコールを開始する。
CTI が INVITE に基づいて NewCallNotify および CtiCallStateNotify（Dialtone/Dialing）を報告する。
JTAPI が、CallActiveEv、および 1000 の connection イベントと terminalConnection イベントを報告する。
CTI が CtiCallStateNotify（Proceeding）を報告する。
JTAPI が 1000 の CallCtlConnEstablishedEv を報告する。
SIP プロキシが 333555@aaa.com の 302 を報告する。302 に基づいて、Cisco Unified Communications Manager が 333777@bbb.com への q 値に基づくターゲット リストに含まれる最初の接点へのコールを開始する。Cisco Unified Communications Manager が RNAR タイマーを開始する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
JTAPI が 333777 への接続作成イベントを報告する。
RNAR タイマーが満了し、これに基づいて Cisco Unified Communications Manager が 555888@cisco.com へのコールを開始する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd/CcNotifyReq に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
JTAPI が 333777 への接続を削除し、555888 への接続を作成する。
CTI は CtiCallStateNotify（Connected）も報告する。
JTAPI が 555888 の CallCtlConnEstablishedEv を報告する。
3XX リダイレクション：Contact Within Cisco Unified Communications Manager Cluster Configured with Call Forward
JTAPI アプリケーションが 1000@ccm.cisco.com を監視している。
Cisco Unified Communications Manager の user1000 が、 333555@aaa.com へのコールを開始する。
CTI が INVITE に基づいて NewCallNotify および CtiCallStateNotify（Dialtone/Dialing）を報告する。
JTAPI が、CallActiveEv、および 1000 の connection イベントと terminalConnection イベントを報告する。
CTI が CtiCallStateNotify（Proceeding）を報告する。
JTAPI が 1000 の CallCtlConnEstablishedEv を報告する。
SIP プロキシが 333555@aaa.com の 302 を報告する。302 に基づいて、Cisco Unified Communications Manager が 2000@ccm.cisco.com への q 値に基づくターゲット リストに含まれる最初の接点へのコールを開始する。
2000@ccm.cisco.com から、486 ユーザ ビジー応答が報告される。2000 にはコール転送ビジーが設定されているため、Cisco Unified Communications Manager が 3000@ccm.cisco.com へのコールを開始する。Cisco Unified Communications Manager は RNAR タイマーも開始する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
3000 は応答せず、RNAR タイマーが満了し、これに基づいて Cisco Unified Communications Manager が 555888@cisco.com へのコールを開始する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd/CcNotifyReq に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
JTAPI が 3000 への接続を破棄し、555888 への接続を作成する。
CTI は CtiCallStateNotify（Connected）も報告する。
JTAPI が 555888 の CallCtlConnEstablishedEv を報告する。
3XX リダイレクション - Non-Available Target Member
JTAPI アプリケーションが 1000@ccm.cisco.com を監視している。
Cisco Unified Communications Manager の user1000 が、 333555@aaa.com へのコールを開始する。
CTI が INVITE に基づいて NewCallNotify および CtiCallStateNotify（Dialtone/Dialing）を報告する。
JTAPI が、CallActiveEv、および 1000 の connection イベントと terminalConnection イベントを報告する。
CTI が CtiCallStateNotify（Proceeding）を報告する。
JTAPI が 1000 の CallCtlConnEstablishedEv を報告する。
SIP プロキシが 333555@aaa.com の 302 を報告する。302 には、 1212@ccm.cisco.com および 2000@ccm.cisco.com のターゲット リストが含まれる。 1212@ccm.cisco.com は無効な DN。Cisco Unified Communications Manager はまず 1212@ccm.cisco.com へのコンタクトを試みるが、無効な DN が返されるため、 2000@ccm.cisco.com へのコールを実行する。
着信者情報が変更された場合、Cisco Unified Communications Manager からの SIPAlertInd に基づいてアプリケーションに CallPartyInfoChange イベントが報告される。
CTI は CtiCallStateNotify（Ringback/Connected）も報告する。
JTAPI が 2000 の CallCtlConnAlertingEv および CallCtlConnEstablishedEv を報告する。
Unicode のサポート
端末の GetLocale と UniCodeCapabilities
下位互換性に関する機能拡張
この機能は、Cisco Unified Communications Manager JTAPI のパフォーマンスやスケーラビリティを変えるためのものではありません。JTAPI と CTI のイベント数に違いはありません。GCID の変更を含む機能には、この機能によって追加イベントが 1 つ導入されます。このイベントは通常、パフォーマンス問題の原因にはなりません。
次に示す各イベントは、どのような場合でも、コントロール リストに 1 つの通話者だけが存在するときコール オブザーバに配信されます。TERMA は A の端末を示します。
A が B にコールし、B がそのコールを C に転送します。GC1 は A と B の間のコールであり、GC2 は B と C の間のコンサルト コールです。Conference やその他の機能についても同様のイベントが配信されます。
A が B にコールします。call=GC1。B はコールを 99999 にパークします。C はコール GC2 を使用してコールをパーク解除します。
A が B にコールし、B は C に対して応答なしコール転送を実行します。B は応答せず、コールが C に提供されます。
A が B にコールし、B がそのコールを C にリダイレクトします。
半二重メディア
|
|
|
|
A - CiscoRTPInputStoppedEv CiscoRTPOutputStoppedEv |
Ev.isHalfDuplex() が false を返し Ev.isHalfDuplex() が false を返す |
|
録音と監視
A および TA は、監視先または録音元のアドレスおよび端末です。
アプリケーション ユーザには録音機能だけが設定されています。
|
|
|
|
|---|---|---|
|
|
|
|
|---|---|---|
CiscoProviderCapabilityChangedEv |
||
|
|
|
|
|---|---|---|
アドレス上の録音ステータスは、アプリケーションによって制御される録音に変更される。 |
CiscoAddressRecordingConfigChangedEv |
自動録音。A には、自動録音が設定されています。発信側 X が A にコールします。A が、コールに応答します。A にはコール オブザーバがあります。TA にはオブザーバがあります。
自動録音。A には、自動録音が設定されています。発信側 X が A にコールします。A が、コールに応答します。アプリケーションが、startRecording() をコールします。
自動録音。A には、自動録音が設定されています。発信側 X が A にコールします。A が、コールに応答します。アプリケーションが、startRecording() をコールします。
StartRecording()。A の録音設定は、アプリケーションにより制御されています。発信側 X が A にコールします。アプリケーションが、startRecording() をコールします。A が、コールに応答します。アプリケーションが、startRecording() をコールします。
stopRecording()。A の録音設定は、アプリケーションにより制御されています。発信側 X が A にコールします。A が、コールに応答します。アプリケーションが、stopRecording() をコールします。
保留。A には、自動録音が設定されています。発信側 X が A にコールします。A が、コールに応答し、コールを保留します。A が、コールを再開します。RTP イベントが端末オブザーバに配信され、それらはコール イベントに依存しません。
会議コントローラおよび録音元。A には、自動録音が設定されています。発信側 X が A にコールします。A が、コールに応答します。A が Y にコンサルト コールを開始します。Y が応答し、A が会議を開催します。
会議の対象および録音元。A には、自動録音が設定されています。発信側 X が Y GC1 にコールします。Y が A にコンサルト コールして、A がコール（GC2）に応答し、Y が会議を開催します。
転送コントローラおよび録音元。A には、録音が設定されています。発信側 X が A にコールします。A が、コールに応答します。A が Y にコンサルト コールを開始します。Y が応答し、A による転送が成立します。
転送先および録音元。A には、自動録音が設定されています。発信側 X が Y GC1 にコールします。Y が A にコンサルト コールして、A がコール（GC2）に応答し、Y による転送を実行します。
次の監視を開始および停止します。A は監視対象、B は監視元です。X が A にコールし、A がコール GC1（ci1）に応答します。B が、GC2 を使用して、監視の開始をコールします。アプリケーションには、A と B の両方にコール オブザーバがあります。アプリケーションには、監視機能が有効化されています。
監視元が、Y にコールを転送します。A は監視対象、B は監視元です。X が A にコールし、A がコール GC1（ci1）に応答します。B が、GC2 を使用して、監視の開始をコールします。アプリケーションには、A と B の両方にコール オブザーバがあります。アプリケーションには、監視機能が有効化されています。B が、Y にコールを転送します。
割り込みされたコールを監視します。A および A' は、共用回線です。送信者が A にコールし、A がコールに応答します。A' が、コールに割り込みします。B が、監視の開始をコールします。
監視および録音。A は、監視対象で、自動録音が設定されています。B は、監視元です。X が A にコールし、A がコール GC1（ci1）に応答します。B が、GC2 を使用して、監視の開始をコールします。アプリケーションには、A と B の両方にコール オブザーバがあります。アプリケーションには、監視機能が有効化されています。
モニタリングで、Remote in Use の共用回線を次のように監視しています。A および A' は、共用回線です。送信者が A にコールし、A がコールに応答します。B が、監視の開始をコールします。アプリケーションには、A' だけにコール オブザーバがあります。B は、A への接続済みコールに監視要求を開始します。A' のコール オブザーバには、開始イベントは配信されません。
監視および録音のためのスナップ ショット イベント。A は、監視対象で、自動録音が設定されています。B は、監視元です。X が A にコールし、A がコール GC1（ci1）に応答し、B が GC2 を使用して監視の開始をコールします。監視および録音セッションの確立後、別のアプリケーションにより、A にコール オブザーバが追加されます。
チェーニングされた会議および録音。A には、自動録音が設定されています。A、B、および C が GC1 で会議中です。A が GC3 を使用して D にコンサルト コールします。D は、Gc4 を使用して、（E および F との）会議を設定し、A のコンサルト コールを会議に追加します。A は会議を開催し、会議はチェーニングされます。
インターコム
設定：端末 T1 には、TargetDN が B、ラベルが Bob、Unicode ラベルが UBob のインターコム回線 A があります。端末 T2 には、インターコム回線 B があります。アプリケーション プロバイダーでは、コントロール リストに T1 と T2 の両方があります。
C、Carol、UCarol は、A および B と同じインターコム グループに属しています。
D、David、UDavid は、A、B、および C と同じインターコム グループに属していません。
設定：端末 T1 はインターコム アドレス B を持ち、端末 T2 はインターコム アドレス A を持っています。アプリケーションは、CiscoTermDeviceStateWhisperEv および他のすべての DeviceState Events が T1 および T2 上で有効となるように CiscoTermEvFilter を設定しています。アプリケーションは、T1 と T2 の両方に端末オブザーバを追加しています。
Do Not Disturb（サイレント）
設定：アプリケーションは、端末 A と端末 B を監視しています。
アプリケーションは、Terminal.addObserver() を使用して、端末 A に端末オブザーバを追加します。フィルタは、setDNDChangedEvFilter によって有効化されます。DND（サイレント）は、端末上で有効化されます。アプリケーションが、CiscoTerminal から getDNDStatus() を呼び出します。
アプリケーションが、イベントの受信用にフィルタを有効化します。アプリケーションは、Terminal.addObserver() を使用して、端末 A に端末オブザーバを追加します。DND（サイレント）は、端末上で有効化されます。アプリケーションが、CiscoTerminal から getDNDStatus() を呼び出します。
|
|
|
|
|---|---|---|
アプリケーションが、イベントの受信用にフィルタを有効化する。アプリケーションが、端末 A に端末オブザーバを追加する |
EVENT_________META_CALL_STARTING CiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: true |
アプリケーションは、Terminal.addObserver() を使用して、端末 A に端末オブザーバを追加します。フィルタは、CiscoTermEvFilter 内の setDNDChangedEvFilter() によって無効化されます。アプリケーションが、CiscoTerminal から getDNDStatus() を呼び出します。
|
|
|
|
|---|---|---|
アプリケーションは、Terminal.addObserver() を使用して、端末 A に端末オブザーバを追加する。フィルタは、CiscoTermEvFilter 内の setDNDChangedEvFilter() によって無効化される。 |
アプリケーションは、端末に端末オブザーバを追加しません。アプリケーションが、CiscoTerminal から getDNDStatus() を呼び出します。
|
|
|
|
|---|---|---|
アプリケーションは、端末に端末オブザーバを追加しない。アプリケーションが、CiscoTerminal から getDNDStatus() を呼び出す。 |
アプリケーションは、イベントの受信用にフィルタを有効化しません。アプリケーションが、端末 A に端末オブザーバを追加します。DND（サイレント）ステータスは、phone または admin ページにより true に設定されます。これにより、アプリケーションは、フィルタによるイベントの受信を有効化します。アプリケーションが、CiscoTerminal から getDNDStatus() を呼び出します。
アプリケーションは、CiscoTerminal で setDNDStatus() インターフェイスを呼び出して、DND（サイレント）ステータスを false に設定します。
|
|
|
|
|---|---|---|
NEW META EVENT_________META_CALL_STARTINGCiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: false |
Application1 および Application2 は、端末 A を監視しており、両アプリケーションはイベントの受信用にフィルタを有効化しています。Application1 は、端末 A で、DND（サイレント）ステータスを false に設定します。Application2 は、端末 A を監視しています。
|
|
|
|
|---|---|---|
NEW META EVENT_________META_CALL_STARTINGCiscoTermDNDStatusChangedEv A Cause: CAUSE_NORMAL for DND Status: false |
DND（サイレント）タイプは RingerOff で、CFNA は設定されていません。端末 B が端末 A をコールします。コールは A に表示されるが、コールは応答されません。
|
|
|
|
|---|---|---|
DND（サイレント）タイプは RingerOff で、CFNA は設定されていない。端末 B が端末 A をコールする。コールは A に表示されるが、コールは応答されない。 |
DND（サイレント）タイプは CallReject で、CFB は設定されていません。端末 B が端末 A をコールします。コールは A に表示されません。
|
|
|
|
|---|---|---|
DND（サイレント）タイプは CallReject で、CFB は設定されていない。端末 B が端末 A をコールする。コールは A に表示されない。 |
DND（サイレント）は、端末 A で有効化されます。端末 A は IN_SERVICE となります。アプリケーションが、ServiceEv の CiscoTerm で getDNDStatus() を呼び出します。
|
|
|
|
|---|---|---|
DND（サイレント）は、端末 A で有効化されます。端末 A は IN_SERVICE となります。アプリケーションが、setDNDStatus() を呼び出します。setDNDStatus() 要求が送信された後、DB 障害が発生します。
|
|
|
|
|---|---|---|
DND（サイレント）は、端末 A で有効化される。端末 A は IN_SERVICE となる。アプリケーションが、setDNDStatus() を呼び出す。DB 障害が発生し、値は DB 内で更新されない。 |
PlatformException で「Could not meet post conditions of setDNDStatus()」がスローされる。 |
DND（サイレント）は、端末 A で有効化されます。端末 A は IN_SERVICE となり、現在、phone/admin の DND（サイレント）ステータスは true です。アプリケーションは同じ値の設定を試みます。つまり、setDNDStatus(true) を呼び出します。
DND-R
アプリケーションは、Terminal.addObserver() を使用して、端末 A に端末オブザーバを追加します。管理ページまたは共通プロファイル ページから、端末 B で DND-R が有効にされます。
アプリケーションは、Terminal.addObserver() を使用して、端末 A に端末オブザーバを追加します。管理ページまたは共通プロファイル ページから、端末 B で DND-R が有効にされています。
セキュア会議
JTAPI Cisco Unified IP 7931G Phone の対話
A および C は、JTAPI アプリケーションで制御可能なアドレスです。B1 および B2 は、Cisco Unified IP 7931G Terminal 上のアドレスです。Cisco Unified IP 7931G Terminal は、アドレス間転送を実行するように設定されています。B1 と B2 は、それぞれ共用回線 B1' と B2' を持ち、JTAPI で制御可能な端末上に設定されています。
ロケール インフラストラクチャ変更シナリオ
シナリオ 1：JTAPI クライアント マシンに CallManager TFTP サーバへの接続がある
• インストール時、JTAPI クライアントはユーザに TFTP IP アドレスの入力を求めることがある。
• TFTP-IP アドレスは JTAPI.ini パラメータに保存される。
• JTAPI Preferences アプリケーションが初めて実行されると、ユーザは言語を選択するための言語タブに誘導される。
• ユーザは JTAPI Preferences アプリケーションを実行する言語を選択できる。
• JTAPI Preferences アプリケーションが 2 回目に実行されると、前にユーザが選択した言語で UI が表示される。
シナリオ 2：JTAPI クライアント マシンに CallManager TFTP サーバへの接続がない
• インストール時、JTAPI クライアントはユーザに TFTP-IP アドレスの入力を求めることがある。
• TFTP-IP アドレスは JTAPI.ini パラメータに保存される。
• JTAPI Preferences アプリケーションが初めて実行されると、ユーザは言語を選択するための言語タブに誘導されるが、ユーザが選択できるのは英語だけである。
• JTAPI Preferences アプリケーションが 2 回目に実行されると、英語で UI が表示される。
• TFTP 接続が復元される。ここで JTAPI Preferences UI が実行されると、ユーザが言語の選択に誘導される。
シナリオ 3：JTAPI クライアント マシンには CallManager TFTP サーバへの接続がある
• インストール時、JTAPI クライアントはユーザに TFTP-IP アドレスの入力を求めることがある。
• TFTP-IP アドレスは JTAPI.ini パラメータに保存される。
• JTAPI Preferences アプリケーションが初めて実行されると、ユーザは言語を選択するための言語タブに誘導される。
• ユーザは JTAPI Preferences アプリケーションを実行する言語を選択できる。
• JTAPI Preferences アプリケーションが 2 回目に実行されると、前にユーザが選択した言語で UI が表示される。
• ここで、新しい言語のサポートが追加された新しいロケール ファイルを使用できる。
• ユーザが JTAPI Preferences アプリケーションを実行すると、JTAPI 初期設定アプリケーションは、ユーザに使用可能であることを通知する。
• アプリケーションは JTAPI Preferences アプリケーションを再起動し、ユーザは新しい言語でサポートされる。
発信側の正規化
シナリオ 1：PSTN 番号（ローカル）から JTAPI によって監視される端末への着信コール
シナリオ 2：国内 PSTN 番号（ローカル）から JTAPI によって監視される端末への着信コール
シナリオ 3：国際 PSTN 番号から JTAPI によって監視される端末への着信コール
シナリオ 4：JTAPI によって監視される端末から PSTN 番号 [SUBSCRIBER] への発信コール
シナリオ 5：JTAPI によって監視される端末から 国内 PSTN 番号への発信コール
シナリオ 6：JTAPI によって監視される端末から国際 PSTN 番号への発信コール
シナリオ 7 ：JTAPI によって監視される端末によって、他の PSTN にリダイレクトされる PSTN からの着信コール
シナリオ 8：PSTN 番号（ローカル）から、JTAPI によって監視される端末（他の JTAPI によって監視される端末に転送する）への着信コール
クリック ツー会議
A、B、C、D はアドレスで、TermA、TermB、TermC、TermD は対応する端末です。
コール ピックアップ
• B と C はコール ピックアップ グループのデバイスである。A はそのグループに含まれないデバイスである。
• C はオフフックになり、[Pickup] ソフトキー（[ピック] ソフトキー）を押す。
C だけを監視することは、お客様がシナリオで行っていたことであったため、この修正では特に配慮しました。この機能要求の目的は、C だけを監視している場合に、ピックアップ時に元の着信側（A）に関する情報を取得できるようにすることでした。すべてのテスト ケースが合格し、それらのすべてについて、正しい情報が表示されました。
これらのテスト ケースは、自動ピックアップを有効にした場合と無効にした場合で実行され、この 2 つの機能は大きく違いました。ほとんどのテスト ケースを下に示します。
A から B への「基本コール」は、すべてのケースで同じであるため、下の最初のケースでだけ示しています。
|
|
|
|
|---|---|---|
A はオフフックになり、B をダイヤルする（基本コール）。B が呼び出し中になる。C はオフフックになり、[Pickup] ソフトキーを押す。C の古い接続はドロップされ、クリーンアップされる。Call 1 で C の接続が確立される。 |
||
（注） 次のシナリオの B と C は共にまったく同じ動作とイベントを発生します。デバイス C（コールをピックアップする）の動作だけ異なります。
自動ピックアップ オプションを有効にしている場合と無効にしている場合で、イベントのフローは大きく異なります。自動コール ピックアップが無効にされており、ユーザが [Pickup] ソフトキー（C）を押すと、電話が鳴ります。ユーザは通常のコールの場合と同様に電話に応答する必要があります。電話が鳴っていて、それらがオフフックになったときに、作成された元のコールが破棄されると、既存のコールに接続され、古い相手（B）がコールから削除されます。「Auto Call Pickup」が無効にされている場合、コールが変更されず、C が新しいコールに参加する前に破棄されるため、CiscoCallChangedEv は生成されません。
グループ ピックアップ シナリオは次のようになります。この場合、[Pickup] ソフトキーの代わりに [Group Pickup] ソフトキー（[Gピック] ソフトキー）が使われます。これは、実際にピックアップ グループの番号をダイヤルする必要があります。さらに、グループ ピックアップには、Auto Call Pickup サービス パラメータが必要です。一般的なフローとコール イベントは、通常のコール ピックアップのシナリオと同じですが、ピックアップ番号の必要なダイヤルに関するイベントが追加されます。グループ ピックアップによる変更を明確に示すために、これらの追加のイベントを表に太字で示しています。
グループ ピックアップと自動ピックアップを有効にしてすべてのデバイスを監視します。
上のグループ ピックアップのケースでは、変更はほんの少しであり、それらはすべてピックアップ番号のダイヤルのために特別に必要な手順に直接関連しています。
グループ ピックアップと自動ピックアップを無効にしてすべてのデバイスを監視します。
上の表は、すべてのデバイスが監視されたときのシナリオを示しています。さまざまなピックアップとグループ ピックアップで、可能なあらゆる組み合わせでデバイスが実行されました。一部のシナリオでは出力がまったく同じであり、重複しているものもあったため、それらはここに示していません。たとえば、デバイス A と B は同じであったため、1 回だけ示しています。
自動ピックアップを有効にして、デバイス C だけを監視します。
自動ピックアップを無効にして、デバイス C だけを監視します。
グループ ピックアップと自動ピックアップを有効にしてデバイス C だけを監視します。
グループ ピックアップと自動ピックアップを無効にして、デバイス C だけを監視します。
コーリングサーチスペースおよび機能プライオリティを使用した selectRoute()
コーリングサーチスペースおよび機能プライオリティを int. の配列として使用した selectRoute() API を次の表に示します。
エクステンション モビリティ ログイン ユーザ名
端末 A はユーザのコントロール リストに含まれ、端末 B はユーザのコントロール リストに含まれていません。エクステンション モビリティ ログイン ユーザ名は John で、アプリケーションのエンド ユーザ ID は John です。
端末 A はユーザのコントロール リストに含まれ、ユーザ Kerry のエクステンション モビリティ ログアウト プロファイルが設定されています。Kerry プロファイルにはログアウト ユーザ名が Kerry として設定されています。ログイン ユーザ名 John の別のプロファイルがあります。
発信側の IP アドレス
• A の IP アドレスは相手 B を監視している JTAPI アプリケーションから使用できる。
• B の IP アドレスは相手 C を監視している JTAPI アプリケーションから使用できる。
• B の IP アドレスは相手 C を監視している JTAPI アプリケーションから使用できる。
• JTAPI アプリケーションは相手 B と相手 C を監視する。
• A の IP アドレスは相手 B を監視している JTAPI アプリケーションから使用できる。
• 発信側の IP アドレスは、相手 B を監視している JTAPI アプリケーションから使用できない（サポートされないシナリオ）。
CiscoJtapiProperties
1) ソケット接続タイムアウトを 5 秒に設定し、プライマリ CTI マネージャのイーサネット ケーブルを引き抜き、通常のプロバイダー オープンを実行します。予想される結果：プライマリ CTI マネージャへのソケット接続が 5 秒以内に失敗します。
2) ソケット接続タイムアウトを 5 秒に設定し、プライマリ CTI マネージャのイーサネット ケーブルを引き抜き、セキュリティ オプションを True に設定して、セキュリティ保護されたプロバイダー オープンを実行します。予想される結果：プライマリ CTI マネージャへのソケット接続が 5 秒以内に失敗します（ソケット接続が 5 秒以内にタイム アウトします。ただし、最初はセキュリティ証明書の確認のため、いくらか余分に時間がかかります）。
3) ソケット接続タイムアウトを 0 秒に設定し、プライマリ CTI マネージャのイーサネット ケーブルを引き抜き、セキュリティ オプションを True に設定して、セキュリティ保護されたプロバイダー オープンを実行します。予想される結果：プライマリ CTI マネージャへのソケット接続で新しいサービス パラメータが使われなくなります（ソケット接続が 23 秒以内にタイム アウトします。ただし、最初はセキュリティ証明書の確認のため、いくらか余分に時間がかかります）。
IPv6 のサポート
使用例 1：基本的なコール シナリオ：発信側が IPv6 対応電話機、着信側が IPv6
使用例 2：基本的なコール シナリオ：発信側が IPv6 対応電話機、着信側が IPv4
使用例 3：基本的なコール シナリオ：発信側が IPv4 対応電話機、着信側が IPv6
使用例 4：基本的なコール シナリオ：発信側が IPv4 対応電話機、着信側が IPv4
使用例 5：コンサルト転送のシナリオ：IPv6 デバイス コンサルト
使用例 6：コンサルト転送のシナリオ：IPv4 デバイス コンサルト
使用例 9：リダイレクトのシナリオ：発信デバイスのリダイレクト
使用例10：ルート シナリオ：IPv6 対応機が RoutePoint をコールし IPv6 デバイスにルート コールする
使用例11：エンタープライズ パラメータ「Enable IPv6」が有効
次の CTI Manager IP のリストを提供すると、アプリケーションによってプロバイダーがオープンされます。
これで、JTAPI は、いったん CTI Manager と接続を確立できますが、後に CTI Manager1 がダウンすると、フェールオーバーの試行で、アプリケーションから見て接続に遅延が発生します。JTAPI は最初に CTI Manger1 の IPv6 アドレス（リストの次）に接続しようとするため、その IP アドレスが同じ CTI Manager のもので、タイムアウトになったのが 1 度だけだとしても、CTI Manager2 の IPv4 アドレスを使用して試行し、成功します（CTI Manager2 が実行中と仮定）。
プロバイダー オープン シナリオ
1. 再接続試行のサービス パラメータは、セットされておらず（あるいは 0 にセットされていて）、エンタープライズ パラメータ「Enable IPv6」は無効化されています。アプリケーションは、IPv4 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI マネージャで接続をオープンできるようになります。
– CTI Manager が停止：JTAPI は、CTI Manager が再起動されて接続が復元されるまで、CTI マネージャに無期限に再接続しようとします。
– エンタープライズ パラメータ「Enable IPv6」は有効化され、CTI マネージャが再起動されます。JTAPI は、同じ IPv4 アドレスで CTI Manager に再接続できるようになります。
2. 再接続試行のサービス パラメータは、セットされておらず（あるいは 0 にセットされていて）、エンタープライズ パラメータ「Enable IPv6」は有効化されています。アプリケーションは、IPv4 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI Manager で接続をオープンできるようになります。
– CTI Manager が停止：JTAPI は、CTI Manager が再起動されて接続が復元されるまで、CTI マネージャに無期限に再接続しようとします。
– エンタープライズ パラメータ「Enable IPv6」は無効化され、CTI マネージャが再起動されます。JTAPI は、同じ IPv4 アドレスで CTI Manager に再接続できるようになります。ただし、IPv6 アドレスで登録された既存のデバイスは、新規の原因コード「IP_CAPABILITY_MISMATCH」で「CiscoTermRegistrationFailedEv」を使用してクローズされます。
3. 再接続試行のサービス パラメータは、セットされておらず（あるいは 0 にセットされていて）、エンタープライズ パラメータ「Enable IPv6」は有効化されています。アプリケーションは、IPv6 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI Manager で接続をオープンできるようになります。
– CTI Manager が停止：JTAPI は、CTI Manager が再起動されて接続が復元されるまで、CTI マネージャに無期限に再接続しようとします。
– エンタープライズ パラメータ「Enable IPv6」は無効化され、CTI マネージャが再起動されます。JTAPI は、もう IPv6 アドレスをサポートしないため、CTI Manager に再接続できませんが、タイム サービス パラメータが再度有効になって CTI Service が再起動されるまで継続して再接続しようとします。
4. 再接続試行のサービス パラメータは、いずれかの整数（たとえば 5）にセットされ、エンタープライズ パラメータ「Enable IPv6」は無効化されています。アプリケーションは、IPv4 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI マネージャで接続をオープンできるようになります。
– CTI Manager は停止：JTAPI は、オープンしているデバイスおよびプロバイダーがすべてクローズするまで、CTI マネージャへの再接続を 5 回試行します。
– エンタープライズ パラメータ「Enable IPv6」は有効化され、CTI マネージャが再起動されます。JTAPI は、同じ IPv4 アドレスで CTI Manager に再接続できるようになります。
5. 再接続試行のサービス パラメータは、いずれかの整数（たとえば 5）にセットされており、エンタープライズ パラメータ「Enable IPv6」は有効化されます。アプリケーションは、IPv4 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI Manager で接続をオープンできるようになります。
– CTI Manager は停止：JTAPI は、オープンしているデバイスおよびプロバイダーがすべてクローズするまで、CTI マネージャへの再接続を 5 回試行します。
– エンタープライズ パラメータ「Enable IPv6」は無効化され、CTI マネージャが再起動されます。JTAPI は、同じ IPv4 アドレスで CTI Manager に再接続できるようになります。ただし、IPv6 アドレスで登録された既存のデバイスは、新規の原因コード「IP_CAPABILITY_MISMATCH」で「CiscoTermRegistrationFailedEv」を使用してクローズされます。
6. 再接続試行のサービス パラメータは、いずれかの整数（たとえば 5）にセットされており、エンタープライズ パラメータ「Enable IPv6」は有効化されます。アプリケーションは、IPv6 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI Manager で接続をオープンできるようになります。
– CTI Manager は停止：JTAPI は、オープンしているデバイスおよびプロバイダーがすべてクローズするまで、CTI マネージャへの再接続を 5 回試行します。
– エンタープライズ パラメータ「Enable IPv6」は無効化され、CTI マネージャが再起動されます。JTAPI は、もう IPv6 アドレスをサポートしないため、CTI Manager に再接続できませんが、JTAPIは、すべてのデバイスおよびプロバイダーがクローズするまで、（同じことが再度 Cisco Unified CM で有効化できるため）CTI Manager にさらに 5 回再接続しようとします。
7. エンタープライズ パラメータ「Enable IPv6」が無効化されます。アプリケーションは、IPv6 アドレスでプロバイダーをオープンしようとします。JTAPI は、CTI マネージャで接続をオープンできません。再試行できるのは、接続がいったん確立できた場合だけですが、このシナリオでは最初の試行から失敗しているため、その後に再接続は試行されません。
エンタープライズ パラメータ「Enable IPv6」が有効化されます。次の CTI Manager IP のリストを提供すると、アプリケーションによってプロバイダーがオープンされます。
これで、JTAPI は、いったん CTI Manager と接続を確立できますが、後に CTI Manager1 がダウンすると、フェールオーバーの試行で、アプリケーションから見て接続に遅延が発生します。JTAPI は最初に CTI Manger1 の IPv6 アドレス（リストの次）に接続しようとするため、その IP アドレスが同じ CTI Manager のもので、タイムアウトになったのが 1 度だけだとしても、CTI Manager2 の IPv4 アドレスを使用して試行し、成功します（CTI Manager2 が実行中と仮定）。
発信側 IP アドレスのシナリオ
1. Ipv6 対応の電話機が、CTI 制御可能デバイスをコールします。続いて、CTI 制御可能デバイスが、JTAPI アプリケーションによって監視されます。JTAPI は、Ipv6 発信側 IP アドレスを含む CiscoCallCtlConnOfferedEv（ルートポイント以外）または CiscoRouteEvent（ルートポイント）の通知を生成します。
getCallingPartyIpAddr() は、null を返します。
getCallingPartyIpAddr_v6() は、実際の発信側 IPv6 アドレスを返します。
2. Ipv4 対応の電話機が、CTI 制御可能デバイスをコールします。続いて、CTI 制御可能デバイスが、JTAPI アプリケーションによって監視されます。JTAPI は、Ipv4 発信側 IP アドレスを含む CiscoCallCtlConnOfferedEv（ルートポイント以外）または CiscoRouteEvent（ルートポイント）の通知を生成します（既存の動作）。
getCallingPartyIpAddr() は、実際の発信側 IPv4 アドレスを返します。
getCallingPartyIpAddr_v6() は、null を返します。
3. Ipv6 電話は、すでに JTAPI アプリケーションによって監視されている CTI 制御可能デバイスだけをコールします。JTAPI は、Ipv6 発信側 IP アドレスを含む CiscoCallCtlConnOfferedEv（非ルートポイント）または CiscoRouteEvent（ルートポイント）の通知を生成します。
getCallingPartyIpAddr() は、null を返します。
getCallingPartyIpAddr_v6() は、実際の発信側 IPv6 アドレスを返します。
4. Ipv4 対応電話は、すでに JTAPI アプリケーションによって監視されている CTI 制御可能デバイスだけをコールします。JTAPI は、Ipv4 形式の発信側 IP アドレスを含む CiscoCallCtlConnOfferedEv（非ルートポイント）または CiscoRouteEvent（ルートポイント）の通知を生成します。
getCallingPartyIpAddr() は、実際の発信側 IPv4 アドレスを返します。
getCallingPartyIpAddr_v6() は、null を返します。
5. Ipv4_v6（デュアル スタック）電話は、CTI 制御可能デバイスをコールします。続いて、CTI 制御可能デバイスが、JTAPI アプリケーションによって監視されます。JTAPI は、Ipv4 および Ipv6 の発信側 IP アドレスを含む CiscoCallCtlConnOfferedEv（非ルートポイント）または CiscoRouteEvent（ルートポイント）の通知を生成します。
getCallingPartyIpAddr() は、実際の発信側 IPv4 アドレスを返します。
getCallingPartyIpAddr_v6() は、実際の発信側 IPv6 アドレスを返します。
6. Ipv4_v6（デュアル スタック）電話は、すでに JTAPI アプリケーションによって監視されている CTI 制御可能デバイスだけをコールします。JTAPI は、Ipv4 および Ipv6 の発信側 IP アドレスを含む CiscoCallCtlConnOfferedEv（非ルートポイント）または CiscoRouteEvent（ルートポイント）の通知を生成します。
getCallingPartyIpAddr() は、実際の発信側 IPv4 アドレスを返します。
getCallingPartyIpAddr_v6() は、実際の発信側 IPv6 アドレスを返します。
RTP アドレス
1. Ipv6 対応電話は、Ipv6 JTAPI によって監視される電話をコールし、その電話が応答します。JTAPI は、次のものを生成します。
– 遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
2. Ipv4 対応電話は、Ipv4 JTAPI によって監視される電話をコールし、その電話が応答します。JTAPI は、次のものを生成します（既存の動作）。
– 遠端 Ipv4 RTP アドレス を含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
3. Ipv4 対応電話は、Ipv6 JTAPI によって監視されるデバイスをコールし、その電話が応答します。JTAPI は、次のものを生成します。
– Call Manager に自動的に挿入され Ipv4/Ipv6 変換を実行する MTP に対応する遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
4. Ipv6 対応電話は、Ipv4 JTAPI によって監視されるデバイスをコールし、その電話が応答します。JTAPI は、次のものを生成します。
– Call Manager に自動的に挿入され Ipv4/Ipv6 変換を実行する MTP に対応する遠端 Ipv4 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
5. デュアル スタック（Ipv4_v6）電話は、他のデュアル スタック（Ipv4_v6) JTAPI によって監視されるデバイスをコールし、優先するメディアの停止が IPv6 にセットされ、そのコールに応答があると、JTAPI は次のものを生成します。
– その発信側デバイスの遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
6. デュアル スタック（Ipv4_v6）電話が、他のデュアル スタック（Ipv4_v6) JTAPI によって監視されるデバイスをコールし、優先するメディアの停止が IPv4 にセットされ、そのコールに応答があってから、JTAPI は次のものを生成します。
– その発信側デバイスの遠端 Ipv4 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
7. デュアル スタック（Ipv4_v6）電話が、Ipv4 JTAPI によって監視されるデバイスをコールし、そのコールに応答があってから、JTAPI は次のものを生成します。
– その発信側デバイスの遠端 Ipv4 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
8. デュアル スタック（Ipv4_v6）電話が、Ipv6 JTAPI によって監視されるデバイスをコールし、そのコールに応答があってから、JTAPI は次のものを生成します。
– その発信側デバイスの遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
9. IPv4 電話が、デュアル スタック（Ipv4_v6）JTAPI によって監視されるデバイスをコールし、そのコールに応答があってから、JTAPI は次のものを生成します。
– その発信側デバイスの遠端 Ipv4 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
10. IPv6 電話が、デュアル スタック（Ipv4_v6）JTAPI によって監視されるデバイスをコールし、そのコールに応答があってから、JTAPI は次のものを生成します。
– その発信側デバイスの遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– 監視対象電話の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
11. JTAPI によって監視される IPv6 電話（A）が、JTAPI によって監視される IPv4 電話（B）をコールします。B が応答し、IPv6 電話（C）に転送を打診します。C が応答し、B が転送を実行すると、JTAPI は次のものを生成します。
– C の遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– A の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
– A の遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– C の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
12. JTAPI によって監視される IPv4 電話（A）が、JTAPI によって監視される IPv4 電話（B）をコールします。B が応答し、IPv6 電話（C）に転送を打診します。C が応答し、B が転送を実行すると、JTAPI は次のものを生成します。
– Call Manager に自動的に挿入され Ipv4/Ipv6 変換を実行する MTP に対応する遠端 Ipv4 RTP アドレスを含む CiscoRTPOutputStartedEv
– A の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
– Call Manager に自動的に挿入され Ipv4/Ipv6 変換を実行する MTP に対応する遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– C の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
13. JTAPI によって監視される IPv6 電話（A）が、JTAPI によって監視される IPv4 電話（B）をコールします。B が応答し、IPv6 電話（C）に会議を打診します。C が応答し、B が会議を開催します。会議ブリッジには、IPv4 アドレスがあります。その後、JTAPI は、次のものを生成します。
– Call Manager に自動的に挿入され Ipv4/Ipv6 変換を実行する MTP に対応する遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
– A の Ipv6 RTP アドレスを含む CiscoRTPInputStartedEv
– 会議ブリッジの遠端 Ipv4 RTP アドレスを含む CiscoRTPOutputStartedEv
– B の Ipv4 RTP アドレスを含む CiscoRTPInputStartedEv
– Call Manager に自動的に挿入され Ipv4/Ipv6 変換を実行する MTP に対応する遠端 Ipv6 RTP アドレスを含む CiscoRTPOutputStartedEv
CTI ポート/ルート ポイント登録シナリオ
1. CTI ポート/ルート ポイントには、「IPv4_v6」として設定された「IPアドレッシング モード」があります。アプリケーションは、IPv6 アドレスと IPv6 としてのアプリケーション アドレッシング機能を使用して、その CTI ポート/ルート ポイントの CTIManager への静的登録を試行します。登録が成功し、CTI ポート/ルート ポイントは、IPv6 アドレスで CTIManager を使用して登録されます。
2. CTI ポート/ルート ポイントには、「IPv4_v6」として設定された「IPアドレッシング モード」があります。アプリケーションは、IPv4 アドレスと IPv4 としてのアプリケーション アドレッシング機能を使用して、その CTI ポート/ルート ポイントの CTIManager への静的登録を試行します。登録が成功し、CTI ポート/ルート ポイントは、IPv4 アドレスで CTIManager を使用して登録されます。
3. CTI ポート/ルート ポイントには、「IPv4_v6」として設定された「IPアドレッシング モード」があります。アプリケーションは、IPv4 および IPv6 のアドレスと IPv4_v6 としてのアプリケーション アドレッシング機能を使用して、その CTI ポート/ルート ポイントの CTIManager への静的登録を試行します。登録が成功し、CTI ポート/ルート ポイントは、IPv4 および IPv6 のアドレスで CTIManager を使用して登録されます。
4. CTI ポート/ルート ポイントには、「IPv4 のみ」として設定された「IPアドレッシング モード」があります。アプリケーションは、IPv4 アドレスと IPv4 としてのアプリケーション アドレッシング機能を使用して、その CTI ポート/ルート ポイントの CTIManager への静的登録を試行します。登録が成功し、CTI ポート/ルート ポイントは、IPv4 アドレスで CTIManager を使用して登録されます。
5. CTI ポート/ルート ポイントには、「IPv6 のみ」として設定された「IPアドレッシング モード」があります。アプリケーションは、IPv6 アドレスと IPv6 としてのアプリケーション アドレッシング機能を使用して、その CTI ポート/ルート ポイントの CTIManager への静的登録を試行します。登録が成功し、CTI ポート/ルート ポイントは、IPv6 アドレスで CTIManager を使用して登録されます。
6. CTI ポート/ルート ポイントには、「IPv4 のみ」として設定された「IPアドレッシング モード」があります。アプリケーションは、IPv6 アドレスの提供と、IPv6（または Ipv4_v6）のみとしてのアプリケーション アドレッシング機能の通知のいずれか、または両方によって、その CTI ポート/ルート ポイントの静的登録を試行し、その後、CiscoRegistrationExceptionas で失敗します。
7. CTI ポート/ルート ポイントには、「IPv6 のみ」として設定された「IPアドレッシング モード」があります。アプリケーションは、そのCTI ポート/ルート ポイントを CTIManager に動的に登録しようとします。登録時にそのアプリケーションによって通知された IP 機能は、IPv4（または IPv4_v6）だけです。その後、その要求は CiscoRegistrationException で拒否されます。
8. CTI ポート/ルート ポイントには、「IPv4 のみ（または IPv4 と v6 両方」として設定された「IPアドレッシング モード」があります。アプリケーションは、その CTI ポート/ルート ポイントを CTIManager に動的に登録しようとします。登録時にそのアプリケーションによって通知された IP 機能は、IPv4 のみです。その後、登録は成功し、CTI ポート/ルート ポイントは、SetRTPParams 要求によって同じものが提供されたときに、IPv4 アドレスで登録されます。
9. CTI ポート/ルート ポイントには、「IPv6 のみ（または IPv4 と v6 両方」として設定された「IPアドレッシング モード」があります。アプリケーションは、そのCTI ポート/ルート ポイントを CTIManager に動的に登録しようとします。登録時にそのアプリケーションによって通知された IP 機能は、IPv6のみです。その後、登録は成功し、CTI ポート/ルート ポイントは、SetRTPParams 要求によって同じものが提供されたときに、IPv6 アドレスで登録されます。
10. CTI ポート/ルート ポイントには、「IPv4_v6 両方」として設定された「IP アドレッシング モード」があります。アプリケーションは、その CTI ポート/ルート ポイントを CTIManager に動的に登録しようとします。登録時にそのアプリケーションによって通知された IP 機能は、IPv4 と v6 両方です。その後、登録は成功し、CTI ポート/ルート ポイントは、SetRTPParams 要求によって同じものが提供されたときに、IPv4_v6 アドレスで登録されます。
11. アプリケーションが、その IP 機能を通知することで CTI ポート/ルート ポイントを IPv6 として動的に登録しようとしても、それはすでに IPv4 アドレスで他のアプリケーションに登録されています。それから、その要求は CiscoRegistrationException で拒否されるか、または「CiscoTermRegistrationFailedEv」が新しい原因コード「IP_CAPABILITY_MISMATCH」と共に送信されます。
拡張テスト ケース
1. アプリケーションは IPv4 アドレスで、エンタープライズ パラメータ「Enable IPv6」が有効化されている CTI Manager に、プロバイダーをオープンします。アプリケーションは、アプリケーション アドレッシング機能を「IPv6 のみ」として通知することで、デバイス IP アドレッシング モードが「IPv4_v6」にセットされている IPv6 アドレスで、CTI ポート/ルート ポイントの登録を試みます。登録要求は成功します。
2. JTAPI によって監視される IPv6 デバイス A が、他の JTAPI によって監視される IPv4 デバイス B をコールし、コールが提供されて B で応答されます。その場合、
CiscoCallCtlConnOfferedEv.getCallingPartyIpAddr() は null を返します。
CiscoCallCtlConnOfferedEv.getCallingPartyIpAddr_v6() は、実際の発信側 IPv6 アドレスを返します。
– CiscoRTPInputStartedEv は、B の IPv4 アドレスを持つようになります。
– CiscoRTPOutputStartedEv は、MTP リソースの IPv4 アドレスを持つようになります。
ここで興味深いのは、発信側 IP アドレスが IPv6 アドレスであるのに対し、CiscoRTPOutputStartedEv が IPv4 アドレスを持つことです。
回線をまたいで直接転送（Direct Transfer Across Lines）の使用例
Connected Conference または回線をまたいで参加（Join Across Lines）の使用例：新しい電話の動作
拡張された MWI の使用例
回線をまたいで参加（Join Across Lines）の拡張機能
A、C、D、E、および F は異なる端末のアドレスです。B1 と B2 は同じ端末 TermB のアドレスです。
A、B1、および C は、B1 がコントローラである電話会議 GC1 に参加し、コンファレンス ブリッジ Conference-1 に接続されています。B2、D、および E は、D がコントローラである電話会議 GC2 に参加し、ブリッジ Conference-2 に接続されています。
コール シナリオ：A、B1、C は、B1 がコントローラである電話会議に参加しています。B2 は、D と GC2 でコール中です。
スワップ/キャンセルおよび転送/会議の動作変更
任意の通話者のドロップ（Drop Any Party）の使用例
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、FALSE にセットされます。
• Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」は、「never」にセットされます。
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、TRUE にセットされます。
• Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」は、「never」にセットされます。
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、FALSE にセットされます。A と A' は共用回線です。
• Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」は、「never」にセットされます。
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、TRUE にセットされます。A と A' は共用回線です。
• Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」は、「never」にセットされます。
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、FALSE にセットされます。
• コントローラが抜けるときに、Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」がセットされます。
|
|
|
|
|
アプリケーションは A の接続で、Connection.disconnect() を呼び出す。 |
CiscoFeatureReason = REASON_NORMAL CiscoFeatureReason = REASON_NORMAL |
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、TRUE にセットされます。
• コントローラが抜けるときに、Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」がセットされます。
|
|
|
|
|
アプリケーションは A の接続で、Connection.disconnect() を呼び出す。 |
CiscoFeatureReason = REASON_NORMAL CiscoFeatureReason = REASON_NORMAL |
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、FALSE にセットされます。
• コントローラが抜けるときに、Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」がセットされます。
• JTAPI INI パラメータが有効化され、dropAnyPartyFeature が許可されます。
• Cisco Unified CM サービス パラメータ「Advanced Ad Hoc Conference Enable」は、TRUE にセットされます。
• コントローラが抜けるときに、Cisco Unified CM サービス パラメータ「Drop Ad Hoc Conference」がセットされます。
パーク モニタリング サポート
電話 B：Cisco Unified IP Phone 7900 Series with SIP/SCCP
電話 A'：Cisco Unified IP Phone 7900 Series with SIP/SCCP
電話 C：Cisco Unified IP Phone 7900 Series with SIP/SCCP
パーク モニタリング復帰タイマーと Park Monitoring Forward No Retrieve タイマーには、すべてのデフォルト値が適用されます。
使用例 1：パーク モニタリングの状態
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。
使用例 2: 共用回線シナリオ：Cisco Unified IP Phone でパークする
最初のシナリオ：アプリケーションは、A、B、A' に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A/A' が鳴ります。A が応答します。
使用例 3：共用回線シナリオ：Cisco Unified IP Phone 7900 Series with SIP でパークする
最初のシナリオ：アプリケーションは、A、B、A' に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A/A' が鳴ります。A' が応答します。
使用例 4: スナップ ショット シナリオの使用例
最初のシナリオ：アプリケーションは、A、B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加していません。B が A をコールします。A が応答します。
使用例 5：パーク DN が監視されている
最初のシナリオ：アプリケーションは、A、B に、コール オブザーバを追加しています。アプリケーションは、パーク DN P1 を監視するため、プロバイダーで registerFeature() API を呼び出します。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。
使用例 6：パークされているコールのクエリ番号
最初のシナリオ：アプリケーションは、A、B、C に、コール オブザーバを追加しています。
使用例 7：フィルタの有効化または無効化
最初のシナリオ：アプリケーションは、A、B に、コール オブザーバを追加しています。B が A をコールします。A が応答します。
使用例 8：フィルタの有効化または無効化
最初のシナリオ：電話 B から A をコールします。A が応答します（コール オブザーバは追加されません）。
|
|
|
|
| • |
|
使用例 9：フィルタの有効化または無効化
最初のシナリオ：電話 B から A をコールします。A が応答します（コール オブザーバは追加されません）。
使用例 10：フィルタの有効化または無効化
最初のシナリオ：アプリケーションは、A、B に、コール オブザーバを追加しています。B が A をコールします。A が応答します。
パーク モニタリングのその他の使用例
電話 B：Cisco Unified IP Phone 7900 Series with SIP/SCCP
電話 A'：Cisco Unified IP Phone 7900 Series with SIP/SCCP
電話 C：Cisco Unified IP Phone 7900 Series with SIP/SCCP
パーク モニタリング復帰タイマーと Park Monitoring Forward No Retrieve タイマーには、すべてのデフォルト値が適用されます。
1. 最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。フィルタの値が setCiscoAddrParkStatusEvFilter() によって「true」にセットされます。
2. 最初のシナリオ：アプリケーションは、A、B、A' に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A/A' が鳴ります。A が応答します。フィルタの値が setCiscoAddrParkStatusEvFilter() によって「true」にセットされます。
3. 最初のシナリオ：アプリケーションは、A、B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加していません。B が A をコールします。A が応答します。フィルタの値が setCiscoAddrParkStatusEvFilter() によって「true」にセットされます。
4. 最初のシナリオ：アプリケーションは、A、B、C に、コール オブザーバを追加しています。フィルタの値が setCiscoAddrParkStatusEvFilter() によって「true」にセットされます。
5. イベント通知を制御するアドレス イベント フィルタを確認する使用例：フィルタの値は setCiscoAddrParkStatusEvFilter() で「false」にセットされます。これもデフォルト値です。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。
6. イベント通知を制御するアドレス イベント フィルタを確認する使用例。フィルタの値は、setCiscoAddrParkStatusEvFilter() で「true」にセットされています。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。
7. イベント CiscoAddrPArkrStatusEv にセットされたフィルタの値を確認する使用例。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。
8. インターコム機能（ターゲット DN とインターコム ターゲット ラベルの一方または両方）が変更されていないときに、CiscoAddrIntercomInfoChangedEv の通知およびイベントのフィルタの値を確認する使用例。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A をコールします。A が応答します。
9. インターコム機能（ターゲット DN とインターコム ターゲット ラベルの一方または両方）が変更されているときに、CiscoAddrIntercomInfoChangedEv の通知およびイベントのフィルタの値を確認する使用例。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A にコールします。A が応答します。
10. CiscoAddrIntercomInfoRestorationFailedEv の通知と、このイベントのフィルタの値を確認する使用例。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A にコールします。A が応答します。
11. CiscoAddrRecordingConfigChangedEv の通知と、このイベントのフィルタの値を確認する使用例。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A にコールします。A が応答します。
録音プロファイルの設定は、変更されていません。
12. CiscoAddrRecordingConfigChangedEv の通知と、このイベントのフィルタの値を確認する使用例。
最初のシナリオ：アプリケーションは、A と B に、コール オブザーバを追加しています。アプリケーションは、A に、アドレス オブザーバを追加しています。B が A にコールします。A が応答します。
DPark 関連の使用例
-アプリケーションは、B および A で、コール オブザーバを追加済みです。
-ユーザには、設定済みの DPark DN D があります。
- B は、Cisco Unified IP Phone の将来モデルです。
- A が B にコールします。B が、GCID GC1 で応答します。
論理パーティション設定機能の使用例
Logical Partition（LP; 論理パーティション）制限クラスタからリダイレクトします。
端末 TA は、アドレス A で設定され、論理パーティション制限で設定されるクラスタに登録されます。端末 TX は、LP 設定のないクラスタに設定されるアドレス X で登録されます。
コール転送：「許可されない」ポリシーで、コール先のアドレスから GeoLocation にある PSTM へ、すべて転送されるコール。
コール転送：GeoLocation にあるコントローラによる、「許可されない」ポリシーでの、別の地域から PSTN へのコールの転送。
|
|
|
|---|---|
電話会議：GeoLocation にあるコントローラによる、「許可されない」ポリシーでの、別の地域から PSTN への電話会議の開催。
|
|
|
|---|---|
プラットフォーム例外が、conference() 要求にスローされる。 getErrorCode() は、CiscoJtapiException.CTIERR_FEATURE_NOT_AVAILABLE を返す。 |
パーク/パーク解除のコール：PSTN コールをパークおよびパーク解除します。
A と B は同じクラスタ内にありますが、LP 制限で、別の地域に設定されています。PSTN は、B と同じ地域です。
|
|
|
|---|---|
| ConnFailedEv A CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED CallCtlConnFailedEv CAUSE: CiscoCallEv.CAUSE_SERVNOTAVAILUNSPECIFIED |
共用回線
TermA と TermA' は、同じクラスタ内にありますが、LP 制限により、別の地域で設定されます。PSTN は、TermA と同じ地域です。
|
|
|
|---|---|
GC1: CallActiveEv |
異なる地域の共用回線でのコール パーク制限
TermA と TermA' は、同じクラスタ内にありますが、LP 制限により、別の地域で設定されます。PSTN は、TermA と同じ地域です。
|
|
|
|---|---|
|
ComponentUpdater 拡張の使用例
|
|
|
|---|---|
IPv6 のサポート
|
|
|
|---|---|
| ステップ 1 の後、IP アドレッシング モードは IPv4 から IPv6 に変わる。ユーザにデバイスのリセットを求めるメッセージが表示される。 ここで、アプリケーションが端末 A で、CiscoTerminal.getIPAddressingMode() を呼び出す。 |
フィードバック