この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco Unified TAPI サービス プロバイダー(TSP)でサポートされている機能について説明します。Cisco Unified Communications Manager のリリースごとの機能の一覧は、新機能および変更情報を参照してください。
Cisco TSP は 3XX の CTI 理由コードを REDIRECT にマップします。3XX の機能によってモニタされている回線に着信があった場合、着信コールのコール理由は REDIRECT になります。TSP 3XX のインターフェイス変更はサポートされていません。
Cisco Unified Communications Manager に次の新しい機能が追加され、SIP を実行している電話機のサポートが拡張されました。
リリース 10.5(2) 以降、Cisco Unified Communications Manager はサポート対象の暗号化アルゴリズムの ID リストを更新しました。CiscoTSP は、SRTP AlgorithmID のリストも更新しました。CiscoLineDevSpecificMsg.h に追加される CiscoSRTPAlgorithm の新しい ID は次のとおりです。
SRTP_AES_CM_128_HMAC_SHA1_80
SRTP_F8_128_HMAC_SHA1_32
SRTP_F8_128_HMAC_SHA1_80
SRTP_AEAD_AES_128_GCM
SRTP_AEAD_AES_256_GCM
SRTP_AEAD_128_GCM と SRTP_AEAD_AES_256_GCM は、2 つの SIP エンドポイント間のセキュア コールでのみネゴシエートします。
CTI ポートは、前述のアルゴリズム ID に登録できますが、セキュア コールをネゴシエートするのは、既存の SRTP_AEAD_128_COUNTER のみです。
エージェント グリーティングを使用すると、CTI アプリケーション(Contact Center など)は、エージェント デバイスへのメディア接続に成功した直後に、事前に録音された音声案内をカスタマーに自動再生するよう、Cisco Unified Communications Manager に指示できます。コールへの応答やグリーティング(例:「○○銀行へお電話ありがとうございます。"担当の佐藤です。"お客様の口座番号を入力してください。」)の再生開始、停止の処理はアプリケーションで管理する必要があります。エージェントとカスタマーはエージェント グリーティングを聞くことができ、エージェントは、グリーティング終了までミュートにするか、グリーティング終了前にカスタマーと会話することができます。エージェント グリーティング機能をサポートするため、Cisco Unified TSP では、エージェント グリーティングの開始および停止用に新しい CCiscoLineDevSpecific 拡張が導入されました。
カスタマーのコール中にエージェントのグリーティングを処理するには、次の作業を実行します。
CCiscoLineDevSpecificStartSendMediaToBIBRequest を使用すると、アプリケーションでカスタマー コールに対するエージェント グリーティングを開始できます。この要求には、IVRDN および CGPNToIVR が含まれます。
CCiscoLineDevSpecificStopSendMediaToBIBRequest を使用すると、アプリケーションでエージェント グリーティングを停止できます。この要求は、エージェント グリーティングが現在再生されている回線に発行されます。その他に必要なパラメータはありません。
エージェント グリーティングが開始または停止されると、Cisco Unified TSP からアプリケーションに LineCallDevSpecific(SLDSMT_MEDIA_TO_BIB_STARTED)または LineCallDevSpecific(SLDSMT_MEDIA_TO_BIB_ENDED)が送信されます。
エージェント グリーティング終了イベントでは、エージェント グリーティングが正常に再生されたかどうかが param2 に示されます。
エージェント グリーティングがエージェントとカスタマーの間のコールに対して再生されている最中に、アプリケーションが別の回線をオープンすると、Cisco Unified TSP は LineCallInfo::DevSpecific の CallAttributeBits ビットマップに SendMediaToBIB ビットマップを設定して、エージェント グリーティングが進行中であることを示します。エージェント グリーティングが終了すると、Cisco Unified TSP からアプリケーションに LineCallDevSpecific(SLDSMT_MEDIA_TO_BIB_ENDED)が送信され、CallAttributeType フィールドの SendMediaToBIB ビットマップはクリアされます。
エージェントのグリーティング コールが IVR ポートに到達すると、2 つの新しいビットマップ(ServerCall および BIBCall)が CallAttributeType として設定されます。エージェントのグリーティング コールが IVR ポートに到達すると、Cisco Unified TSP は TAPI コール理由として LINECALLREASON_UNKNOWN を設定し、ExtendedCallReason フィールドに CtiReasonSendMediaToBIB を設定します。
CTI ポートおよびルート ポイントは、エージェント グリーティングをサポートしていません。CTI ポートまたはルート ポイントに対して CCiscoLineDevSpecificStartSendMediaToBIBRequest を発行すると、アプリケーションは LINEERR_OPERATIONUNAVAIL を受信します。
(注) | この機能をサポートするには、アプリケーションが回線拡張バージョン 0x000B0000 以上でネゴシエートする必要があります。 |
BIB に対するメディアの送信開始、BIB に対するメディアの送信停止、メディアの BIB 開始イベント、メディアの BIB 終了イベント、および詳細(Details)を参照してください。
エージェントのグリーティングを参照してください。
エージェントの Zip トーン サポート機能を使用すると、TAPI アプリケーションはアクティブ コールに対してトーンを再生できます。つまり、エージェントがコールに応答した(アクティブ状態)後にエージェントの電話機でトーンを再生できます。
TAPI は、新しい回線の devspecific CCiscoLineDevSpecificPlaytone(lineHandle、callHandle、Tone、および PlayToneDirection)メッセージ タイプを定義します。アプリケーションでは、このメッセージ タイプを使用して、ローカルまたはリモートの電話機でトーンを再生します。
アプリケーションは、コールが Accepted/Ringback 状態の場合にローカルの電話機でトーンを再生でき、コールが Connected 状態の場合にリモートの電話機でトーンを再生できます。
アプリケーションから、トーンを CTONE_ZIP、方向をローカルとした CCiscoLineDevSpecificPlaytone 要求が発行されると、ローカルの電話機で Zip トーンが再生され、
LINE_DEVSPECIFIC イベントが、次のパラメータとともにローカルの電話機に報告され、トーンの再生が示されます。
同様に、アプリケーションから、トーンを CTONE_ZIP、方向をリモートとして CCiscoLineDevSpecificPlaytone 要求が発行されると、リモートの電話機で Zip トーンが再生され、
LINE_DEVSPECIFIC イベントが、次のパラメータとともにリモートの電話機に報告され、トーンの再生が示されます。
同時に、ローカルの電話機では、LINE_DEVSPECIFIC イベントが次のパラメータとともに報告されます。
拡張バージョン 0x000B0000 は、リリース 8.5(1) で導入されました。
エージェントの zip トーンを参照してください。
エージェントの zip トーンを参照してください。
一部の機種の IP Phone では、電話機上で設定可能なロケールに対応するデフォルト スクリプト以外の代替言語スクリプトがサポートされています。たとえば、日本語ロケールには 2 つの表記スクリプトがあります。一部の機種では Katakana スクリプト(デフォルト)しかサポートされていませんが、その他の機種ではデフォルト スクリプトと Kanji スクリプト(代替スクリプト)の両方がサポートされています。アプリケーションは電話機に表示用のテキスト情報を送信できるため、電話機がどの代替スクリプトをサポートしているかを確認する必要があります。
アラビア語とヘブライ語はインストール時に選択することもできますが、Cisco TSP の設定ユーザ インターフェイスで選択することもできます。
Cisco Unified Communications Manager は、割り込みと C 割り込み機能をサポートしています。割り込み機能では、電話機に組み込みの会議ブリッジが使用されます。C 割り込み機能では、共有会議リソースが使用されます。
Cisco Unified TSP は、割り込み機能および C 割り込み機能が呼び出されたことによって発生するイベントをサポートします。Cisco Unified TSP の API から割り込みまたは C 割り込みを呼び出すことはできません。
コール制御ディスカバリ機能では、コール間エージェント通信のためのプロビジョニングが容易になります。この機能は、SAF(Service Advertisement Framework)ネットワーク サービスを使用して、それ自体をコール制御エンティティとして通知するとともに、ネットワーク上の他のコール制御エンティティ(CUCM や CME)を検出することで、そのルーティング動作をダイナミックに調整することができます。
異なるクラスタ上の 2 つのデバイス間にコールが確立されたものの、ICT 帯域幅の制限のためにそのコールが接続できない場合、CCD 機能によってそのコールを PSTN トランク経由でフェールオーバーして同じ宛先に接続します。PSTN フェールオーバーはまた、検出済みのホステッド DN パターンが、未割り当て、未指定の番号およびユーザ ビジー以外の原因コードによって拒否された場合に、CCDRequestingService によっても開始されます。
TAPI は、lineCallInfo の devSpecific 部分にある既存の ExtendedCallReason フィールドで、CtiReasonSAF_CCD_PSTNFailover を渡します。TAPI では、TAPI のコール理由フィールド(CallReason)は一度だけ設定されるので、TAPI のコール理由は、LINECALLREASON_DIRECT のままになります。
を参照してください。 Call Control Discovery(呼制御ディスカバリ)
発呼側の IP アドレス機能では、発呼側の IP アドレスが提供されます。発呼側のデバイスは、サポートされている IP Phone である必要があります。IP アドレスは、LINECALLINFO の DevSpecific データを使用して、アプリケーションに提供されます。この値がゼロ(0)の場合は、情報が使用できないことを示します。
機能拡張により、基本的なコール、転送や会議に使用されるコンサルト コール、および基本的なリダイレクトや転送の着信側に、IP アドレスが提供されます。発信側が変更された場合は、サポートされません。
発信側の IP アドレスを参照してください。
Cisco Unified Communication Manager Release 7.0(1) よりも前のバージョンでは、"+" 記号はサポートされていませんでした。発信者のローカライズ ナンバーやグローバル ナンバーは着信側のアラート ディスプレイ上に表示されず、また、[編集(EditDial)] の必要なくコールバックできるような発着信履歴への登録もサポートされていませんでした。
Cisco Unified Communications Manager Release 7.0(1) では "+" 記号のサポートが追加され、発信者番号もグローバル化されてアプリケーションに渡されるようになりました。これによって、エンド ユーザは [編集(EditDial)] を使用せずにコール バックできるようになりました。グローバル化された発呼側とともに、ユーザは発呼側の番号タイプも知ることができます。これによって、ユーザは、コールの発信地、つまり、それが SUBSCRIBER、NATIONAL、INTERNATIONAL のいずれの番号なのかを知ることができます。
LINECALLINFOを参照してください。
発信側の正規化を参照してください。
コール ピックアップ機能により、TAPI アプリケーションは、ピックアップ、グループ ピックアップ、他グループ ピックアップ、およびダイレクト ピックアップ機能をアプリケーションから起動できます。コール ピックアップ機能を起動するための API が提供されているだけでなく、アプリケーションはコール ピックアップ グループを登録することで、ピックアップできるコールが発生したときに、アラート通知を受け取ることができます。コールが設定された時間以内にピックアップされ、アラートが停止された場合は、通知されません。
ピックアップ グループに新しいコールが発生すると、TAPI は LINE_APPNEWCALL イベントを発行した後、LINECALLSTATE_UNKNOWN | CLDSMT_CALL_PICKUP_STATE を指定して LINE_CALLSTATE を発行します。
拡張バージョン 0x000A0000 以上を指定して LineGetDevCaps API を起動すると、LINEDEVCAPS の devSpecific データの回線に対して、ピックアップ グループの番号とパーティションが TAPI によって割り当てられます。
この機能には、新しい LineType が追加されており、アプリケーションは、ピックアップ回線の LINEDEVCAPS の Devspecific 部分で使用できます。
#define LINEDEVCAPSDEVSPECIFIC_PICKUPDN 0x00000004
新しい API を使用するためには、拡張バージョン 0x000A0000 以上でネゴシエートする必要があります。
ピックアップ回線の固定回線 ID の範囲は、MAX_PICKUP_PERMID と MIN_PICKUP_PERMID の間です。
const DWORD MAX_PICKUP_PERMID = 0xFFFFFFFF;
const DWORD MIN_PICKUP_PERMID = 0xFF000000;
この機能に対して、新しい Call State Callpickup State が追加されました
#define CLDSMT_CALL_PICKUP_STATE 0x10000000
RegisterCallPickUpGroupForNotification、UnRegisterCallPickUpGroupForNotification、およびCallPickUpRequestを参照してください。
を参照してください。 コール ピックアップ
Cisco Unified Communications Manager のキューイング機能は、コール分配機能が同時に分配できるコール数を超えるコールを受けた場合、ハントメンバがコールに応答できるようになるまで、発信者をキュー内で待ち状態にする機能を提供します。コールがキューにある間、ユーザには最初のグリーティング アナウンス、保留音、繰り返されるアナウンスなどが与えられます。
TAPI は、LINECALLINFO 構造体の DevSpecific 部分の extendedCallInfo でそれぞれの状態の下記のコール理由を提供します。
CallQueue {45(0x2D)}
コール理由 CallQueue は、HuntGroup のすべての HuntMember がビジーの場合にコールがキューイングされるときに発呼側のコールで提供されます
CallDeQueue {46(0x2E)}
コール理由 CallDeQueue は、キュー解除されたコールが使用可能な Huntmember または Huntmember が使用できない場合はキューイング機能で設定された他の DN で提供されるときに、接続先コールで提供されます
CallDeQueueTimerExpired {47(0x2F)}
コール理由 CallDeQueueTimerExpired は、キュー処理コール タイマーが期限切れになり、[キュー内の最大待機時間(Maximum Wait Time in Queue)] が経過してキューイング機能で設定された DN でコールが提供されるときに、接続先コールで提供されます
CallDeQueueAgentsBusy {48(0x30)}
コール理由 CallDeQueueAgentsBusy は、すべてのハント メンバがビジーのため、コールがキューイングされず [キューで許可されている最大発信者数(Maximum Number of Callers Allowed in Queue)] に達して、キューイング機能で設定された DN で直接提供されるときに、接続先コールで提供されます
CallDeQueueAgentsUnavailable {49} 0x31()
コール理由 CallDeQueueAgentsUnavailable は、ハント メンバがログインしていないか、または登録されておらず、「ハント メンバがログインまたは登録されていない」場合にキューイング機能で設定された DN でコールが提供されるときに、接続先コールで提供されます
TAPI は、コールがキューイングされるときに、発呼側で、LINECALLINFO の DevSpecific 部分で ConnectedHuntPilotDN を提供しません。connectedHuntPilotDN は、いずれかのハント メンバで提供されたキュー解除済みコールが応答され、接続状態になったときに更新されます。
次のコール キュー設定コンフィギュレーションは、[ハントパイロットの設定(Hunt Pilot Configuration)] ページで使用可能です。
[キューで許可されている最大発信者数(Maximum Number of Callers Allowed in Queue)](1 ~ 100):これは、キュー項目数の設定で、いずれかの時点でキューにいられるコール最大数が反映されます。
[キューが最大数に達した場合の接続先(Destination When Queue is full)]:キュー制限で許可されるコールの最大数に達したときにコールが転送されるユーザ設定可能な接続先番号。
[キュー内の最大待機時間(Maximum Wait Time in Queue)](10 ~ 3600 秒):コールをキューに保存するユーザ設定可能な最大待機時間。
[最大待機時間に達した場合の接続先(Destination When Maximum Wait Time is Met)]:キューの最大待機時間に達したときにコールが転送される先の、ユーザ設定可能な宛先 DN。
[ログインまたは登録されたエージェントが存在しない場合の接続先(Destination When There Are No Agents Logged In or Registered)]:ハント パイロットのハント メンバが登録またはログインされていない場合にキュー機能がコールを転送する、ユーザ設定可能な接続先 DN。
コール キューイングを参照してください。
コール録音機能は、エージェントとカスタマーの間の会話を録音する 2 つの方法(自動コール録音と選択的コール録音)を提供します。どちらのモードが有効であるかは、ライン アピアランスの設定によって決定されます。管理者は、ライン アピアランスに対して、録音なし、すべてのコールの自動録音、または選択的録音を設定できます。選択的コール録音では、録音は、デバイス、CTI 対応アプリケーション、またはその両方(交互)に割り当てられているソフトキーまたはプログラム可能な回線キーを使用して開始できます。
選択的録音は 2 種類のモード(サイレント録音およびユーザ録音)をサポートしています。
サイレント録音モードでは、コール録音ステータスは、Cisco IP デバイス上に表示されません。サイレント録音は通常、コール センター環境で、スーパーバイザがエージェント コールを録音できるようにするために使用されます。スーパーバイザ デスクトップで実行する CTI 対応アプリケーションは、一般にエージェントとカスタマー間のコールの録音を開始および停止するために使用されます。
ユーザ録音モードでは、コール録音ステータスは、Cisco IP デバイス上に表示されます。録音はユーザのデスクトップで実行されるソフトキー、プログラム可能な回線キー、または CTI 対応アプリケーションを使用して開始または停止できます。
ライン アピアランスの録音設定はアプリケーション側で変更できません。TSP は、LineDevCaps 構造体の devSpecificData で、「録音タイプ」情報をアプリケーションに報告します。「録音タイプ」が変更されると、TSP からアプリケーションに LINE_DEVSPECIFIC(LPCT_RECORDING_TYPE の表示を含む SLDSMT_LINE_PROPERTY_CHANGED)イベントが通知されます。
自動コール録音が有効になっている場合は、該当するライン アピアランスでコールが受信または発信されるたびに、録音セッションが開始されます。アプリケーションによる選択的コール録音が有効になっている場合は、コールがアクティブになった後、アプリケーションからそのコールに対して CCiscoLineDevSpecificStartCallRecording (SLDST_START_CALL_RECORDING) を呼び出すことで録音セッションを開始できます。選択的な録音はコールの途中に発生することがありますが、自動録音は、常にコールの開始時に開始します。レコーダは、SIP トランク デバイスとして CallManager に設定されます。レコーダの DN はアプリケーションで変更できません。
TSP は、録音セッションを確立するために、lineDevSpecific を使用してアプリケーションに録音開始要求を送信します。アプリケーションからは、TSP への入力として、録音開始要求で toneDirection を指定する必要があります。録音セッションが確立すると、録音対象となるコール(エージェントとカスタマーの間のコール)の 2 つのメディア ストリームが、エージェントの電話機からレコーダに中継されます。TSP は、LINECALLINFO の devSpecificData でエージェントの CCM コール ハンドルを提供します。
TSP は、LINE_CALLDEVSPECIFIC(SLDSMT_RECORDING_STARTED)イベントを送信することによって、コールの録音が開始されたことをアプリケーションに通知します。録音が開始されると、TSP は LINECALLINFO の DevSpecific データを使用して、録音中のコールの属性情報(deviceName、DN、およびパーティション)を提供します。
コールが終了するか、またはアプリケーションが lineDevSpecific – CCiscoLineDevSpecificStopCallRecording (SLDST_STOP_CALL_RECORDING) を通じて TSP に録音停止要求を送信すると、録音セッションが終了します。録音停止要求によって録音が停止されると、TSP は LINE_CALLDEVSPECIFIC (SLDSMT_RECORDING_ENDED) をエージェントに送信して通知します。
録音およびモニタリングは、同一クラスタ内の IP 電話と CTI でサポートされ SIP を実行している電話機に対してだけサポートされます。これらの機能を呼び出せるのは、ビルトイン ブリッジ(BIB)をサポートしている電話機に対してだけです。デバイス上のコールをモニタリングまたは録音するには、Unified CM の管理画面からビルトイン ブリッジをオンにする必要があります。モニタリングする側の通話者で BIB が設定されている必要はありません。現時点で、セキュア コールでの録音およびモニタリングはサポートされません。
コール属性は、LINECALLINFO 構造体の DEVSPECIFIC 部分にあります。サイレント モニタリングとコール録音は同時に実行される場合があるため、コール属性情報は配列形式で提供されます。
DWORD CallAttrtibuteInfoOffset; DWORD CallAttrtibuteInfoSize; DWORD CallAttrtibuteInfoElementCount; DWORD CallAttrtibuteInfoElementFixedSize;
typedef struct CallAttributeInfo{ DWORD CallAttributeType; DWORD PartyDNOffset; DWORD PartyDNSize; DWORD PartyPartitionOffset; DWORD PartyPartitionSize; DWORD DeviceNameOffset; DWORD DeviceNameSize; }CallAttributeInfo;
{ CallAttribute_Regular = 0, CallAttribute_SilentMonitorCall, CallAttribute_SilentMonitorCall_Target, CallAttribute_RecordedCall, CallAttribute_WhisperCoachingCall, CallAttribute_WhisperCoachingCall_Target, CallAttribute_Recorded_Automatic, CallAttribute_Recorded_AppInitiatedSilent, CallAttribute_Recorded_UserInitiatedFromApp, CallAttribute_Recorded_UserInitiatedFromDevice } ;
録音されたコールの場合、アプリケーションが 0x000C0000 未満の拡張をネゴシエートすると、CallAttributeType は CallAttribute_RecordedCall に設定されます。アプリケーションが 0x000C0000 以降の拡張バージョンとネゴシエートすると、CallAttributeType は CallAttribute_Recorded_Automatic、CallAttribute_Recorded_AppInitiatedSilent、CallAttribute_Recorded_UserInitiatedFromApp、または CallAttribute_Recorded_UserInitiatedFromDevice に設定されます。
Cisco Unified Communications Manager リリース 9.0 では、コール録音機能は、現在のアクティブなコール録音を IP 電話機のソフトキーを押して開始/停止することができます。録音キーは開始と停止モードを切り替えます。
TAPI アプリケーションが録音開始/停止 API を呼び出すと、ユーザが自分の IP 電話機で録音キーを押す場合と同じ効果が得られます。さらに、電話機で進行中の録音を表示するかどうかをアプリケーションで制御できます。
TAPI アプリケーションに録音設定と録音タイプを報告するために Cisco TSP が使用するデータ タイプは、UCM の最新の変更を反映して改訂しました。
この拡張機能のメッセージ シーケンスに変更はありません。
この機能は下位互換性があります。
この拡張機能により、TAPI アプリケーションは、CFwdAll ソフトキーを使用して作成されたコールとオフフック コール(発信コール)を区別できるようになりました。
TAPI は、既存のビットマスク、CallAttributeBitMask で、LINECALLINFO::DEVSPECIFIC の一部として、2 つの新しい追加のマスク ビットを用意しています。新しいマスクは、通常の発信コールでは 0 に設定されます。一方、不在転送機能の有効/無効の切り替えによりコールが生成された場合、この新しいビットは 1 に設定されます。
この機能は、オンフック デバイスでユーザが CFwdAll ソフトキーを押した場合には対応しますが、ユーザがまず受話器を外してから CFwdAll ソフトキーを押した場合には対応しません。
CallAttributeBitMask フィールドでは、LINECALLINFO::DEVSPECIFIC が 2 つの新しいビット マスク(TSPCallAttribute_CallForwardAllSet と TSPCallAttribute_CallForwardAllClear)を含むように変更されます。詳細については、詳細(Details)を参照してください。
不在転送通知を参照してください。
Cisco Unified TSP は自動更新機能をサポートしており、クライアント コンピュータに最新のプラグインをダウンロードしてインストールできます。新しいプラグインは、接続されている CTIManager の QBE と互換性があります。Cisco Unified Communications Manager を新しいバージョンにアップグレードし、Cisco Unified TSP の自動更新機能を起動すると、そのアップグレードした Cisco Unified Communications Manager と互換性のある最新の Cisco Unified TSP がユーザに届きます。この機能により、新しいリリースでもアプリケーションが期待通りに動作するようになります(ただし、新しい Cisco Unified Communications Manager のインターフェイスが TAPI インターフェイスとの下位互換性を維持していることが条件)。アプリケーションは、クライアント コンピュータのローカルにインストールされた Cisco Unified TSP を利用することにより、Cisco Unified TSP の設定の一環として自動更新オプションを設定できます。Cisco Unified TSP の更新方法には、次のオプションがあります。
Cius などのシスコによって導入されたワイヤレス デバイスには、WiFi ネットワーク間および WiFi と VPN ネットワーク(3G/4G)間で移動し、同じ CiscoUCM への登録状態を保持する機能があります。ただし、ネットワークの変更により、デバイスの IP アドレスが変更される場合があります。同じシナリオを Cius 電話機のドックおよびドック解除に適用できます。
Cius などのワイヤレス デバイスの IP アドレスのこの変更を示すために、TAPI は DEVCAPS 構造体を介して lineDevices および phoneDevices の変更された IP アドレスを提供します。
TAPI は、Cius デバイスの lineDevices の IP アドレス情報の変更に関する通知をアプリケーションに送信します。LINE_DEVSPECIFIC 通知が Cius デバイスで開いているすべての回線に対して発行されます。TSP は、param1 =SLDSMT_LINE_PROPERTY_CHANGED と param2 =LPCT_DEVICE_IPADDRESS の指定で LINE_DEVSPECIFIC イベントを発行します。
TAPI は phoneDevices の IP アドレス情報の変更に関する通知をアプリケーションに送信します。PHONE_DEVSPECIFIC 通知が phoneDevices に対して発行されます。TSP は、param1 =CPDSMT_PHONE_PROPERTY_CHANGED_EVENT と param2 =PPCT_DEVICE_IPADDRESS の指定で PHONE_DEVSPECIFIC イベントを発行します。
TAPI は、lineGetDevCaps API が拡張バージョン 0x00090001 以上で呼び出されると、変更された IP アドレス、LINEDEVCAPS の DevSpecific データの lineDevices の IP アドレッシング モード(IPv4、IPv6)を提供します。
TAPI は、phoneGetDevCaps API が拡張バージョン 0x00090001 以上で呼び出されると、変更された IP アドレス、PHONEDEVCAPS の DevSpecific データの phoneDevices の IP アドレッシング モード(IPv4、IPv6)を提供します。
(注) | Cius デバイスは SIP エンド ポイントであり、他のすべての SIP エンド ポイントと同様に、現在 IPV6 をサポートしません。 |
Cius セッションの永続性を参照してください。
クリック ツー会議機能によって、ユーザは、コンサルト コールをせずにインスタント メッセージ(IM)のアプリケーションから会議を開催できます。Cisco TSP は、この機能を既存の会議モデルとして扱います。しかし、会議の開催または終了時に、CtiExtendedReason が Click2Conference となることもあります。
クリック ツー会議を参照してください。
Cisco Unified Communications Manager 10.0(1) 以降では、ユーザ ログイン パスワードの暗号化に使用される暗号化方式が強化されています。CiscoTSP の旧クライアント(9.x 以前)は対称キー暗号化を使用します。リリース 10.x から、CiscoTSP クライアントは非対称および対称暗号化のメカニズムを組み合わせて使用するよう強化されています。この強化は非セキュアな接続のユーザ クレデンシャルのセキュリティを強化します。
このセキュリティ強化を利用するため、アプリケーションやユーザが Cisco TAPI クライアントをアップグレードすることをお勧めします。
CTI からの下位互換性を維持するために、新しい CTI サービス パラメータ [公開キー暗号化が必要(Require Public key Encryption)] が導入されています。
このリリースのこのサービス パラメータのデフォルト値は [False] です。
[On False]:CTI/CUCM は、対称暗号化方式と非対称の公開キー暗号化方式を使用しているアプリケーション/CiscoTSP クライアントは CUCM に接続できるようになります。
[True時(On True)]:PublicKey の非対称暗号化方式を使用する CiscoTSP クライアント/アプリケーションのみ、Cisco Unified Communications Manager 10.x を搭載したプロバイダーを開くことができるようになります。
アプリケーションが Cisco TAPI クライアントをアップグレードし、このサービス パラメータを「True」に設定することをお勧めします。今後のリリースの計画では、このサービス パラメータのデフォルト値として True を設定し、後で廃止して、アプリケーションが対称暗号化方式を使用する旧 CiscoTSP クライアントを使用しないようにします。
この機能には、インターフェイスの変更はありません。
前述のように、新しい CTI サービス パラメータは下位互換性を維持するために追加されます。
Cisco Unified Communication Manager には次の拡張機能が追加されています。
コントローラでなくてもアドホック会議に新しい通話者を追加できるようになりました。
コントローラ以外の会議参加者の CONNECTED コールに対して lineGetCallStatus を発行して、新しい通話者を会議に追加する前に dwCallFeatures を確認できるようになりました。その参加者が新しい通話者を追加できる場合は、dwCallFeatures リストに PREPAREADDCONF 機能が含まれている必要があります。
複数の会議を連結できるようになりました。
これらの機能は、Cisco Unified Communications Manager で「Advanced Ad-hoc Conference」サービス パラメータが有効になっている場合にだけ使用可能です。
このサービス パラメータが有効から無効に変更されると、アドホック会議をそれ以上連結できなくなります。ただし、すでに連結された会議は、そのまま保持されます。この変更が行われる前にコントローラ以外の通話者によってアドホック会議に追加された参加者はそのまま会議に残りますが、新しい参加者を追加したり既存の参加者を削除することはできなくなります。
すべての参加者が退出した後もアドホック会議リソースの接続状態が継続するのを防ぐため、Cisco Unified Communications Manager では、同じアドホック会議に 3 つ以上の会議リソースを接続することは禁止されます。ただし、スター トポロジを使用して複数の会議を接続すると、リニア トポロジよりも音声品質が良くなる場合があります。管理者は、新しい拡張サービス パラメータ「Non-linear Ad Hoc Conference Linking Enabled」を使用することで、スター トポロジを選択できます。
参加者は、Conference コマンド、Transfer コマンド、または Join コマンドを使用して 2 つの会議を連結できます。2 つの会議が連結された場合、各参加者に対して表示されるのは、各自が属している会議の参加者だけであり、連結された会議は一意の会議ブリッジ名を持つ参加者として表示されます。つまり、参加者に対しては、連結された会議の一部しか表示されないことになります。すべての参加者が相互に会話をしている場合であっても、それらの会議は 2 つの独立した会議として扱われます。
以下の図は、会議を連結した場合に TSP で会議モデルがどのように表現するかを示します。A、B、および C は会議 1 に属し、C、D、および E は会議 2 に属します。C は、会議 1 において ONHOLD 状態のコール、会議 2 においてアクティブ コールを実行中です。
その後、C が、会議 1 のプライマリ コールを使用して参加を実行します。A、B、および C から見た場合、会議参加者は A、B、C、および会議 2 です。また、D および E から見た場合、会議参加者は D、E、および会議 1 です。
ユーザが電話機の会議リストからいずれかの会議を削除すると、連結された会議ブリッジが実際に切断されます。この例では、連結された 2 つの会議が再び分離されます。会議 1 はアクティブな状態で残り、参加者は、A、B、および C になります。それに対して、会議 2 の参加者は Dave と Ed の 2 人だけになるため、会議 2 は Dave と Ed の間の直接コールに変わります。
アプリケーションで会議を連結するには、2 つの独立した電話会議に対して JOIN または TRANSFER を発行します。ただし、LineCompleteTransfer で会議オプションを指定すると、Microsoft TAPI の制約により、標準 API においてエラーが発生します。Cisco LineDevSpecific 拡張を使用して Join 要求を発行すると、アプリケーションで複数の会議を連結できます。
(注) | Cisco Unified Communications Manager Release 8.6 の時点では、JTAPI/TSP を利用した Cisco TelePresence MCU 会議ブリッジがサポートされます。JTAPI/TSP から見ると、これらの会議ブリッジは他のサポートされている会議ブリッジと同様に動作します。 |
CTI ポート デバイスをファーストパーティ モードでオープンするとは、アプリケーション自体が CTI ポートでメディアを終端すること、またはアプリケーションが Cisco Wave Driver を使用して CTI ポートでメディアを終端することを意味します。このことを、CTI ポート デバイスの登録ともいいます。
サードパーティ モードで CTI ポートをオープンするとは、アプリケーションは CTI ポートをオープンするだけで、CTI ポート デバイスでのメディアの終端は行わないことを意味します。このような例としては、別のアプリケーションによってすでにファーストパーティ モードでオープンまたは登録されている CTI ポート デバイスを監視するために、サードパーティ モードで CTI ポートをオープンするケースがあります。CTI ポートをサードパーティ モードでオープンしても、回線または回線上のコールのコール制御操作が妨げられることはありません。
Cisco Unified TSP を使用すれば、TAPI アプリケーションで lineDevSpecific API を使用して CTI ポート デバイスをサードパーティ モードでオープンできます。ただし、アプリケーションが拡張バージョン 6.0(1) 以上をネゴシエートし、さらに上位ビットを設定して、拡張バージョンが 0x80050000 以上に設定されている必要があります。
TAPI のアーキテクチャでは、同じ PC 上で動作する 2 つの異なる TAPI アプリケーションが同じ Cisco Unified TSP を使用することが可能です。この場合、両方のアプリケーションが CTI ポートをオープンしようとすると問題が発生する可能性があります。そのため、2 番めのアプリケーションがどちらのモードで CTI ポートをオープンできるかは、先に CTI ポートをオープンしたアプリケーションによって制御されます。つまり、同じ PC 上で同じ Cisco Unified TSP を使用して動作しているすべてのアプリケーションが同じモードで CTI ポートをオープンする必要があります。別のアプリケーションが異なるモードで CTI ポートをオープンしようとした場合、lineDevSpecific() 要求は失敗します。
この機能は、ユーザのサードパーティ製デバイス上のコール制御機能をモニタし、制限する機能を拡張するために TSP/CTI アプリケーションを提供します。この機能は、ユーザのサードパーティ製デバイス/エンド ポイントのすべてを「CTI リモート デバイス」という仮想デバイス タイプで設定されたリモート接続先として表示することで、ユーザに提供されます。
「CTI リモート デバイス」は仮想デバイスの新しいタイプで、他のデバイスと同様に管理ページから設定できます。これはモビリティ サポートが有効になっているエンド ユーザに関連付ける必要があります。リモート接続先は、[CTI リモート デバイス(CTI Remote Device)] ページで設定でき、これらの各リモート接続先には、サードパーティ製デバイス(PSTN、モバイルまたは他の PBX)にダイヤルするために使用できる番号が設定されます。そのため、リモート接続先のそれぞれが Unified Communications Manager に実際に登録されていないユーザのサードパーティ製デバイスの 1 つを表します。
「CTI リモート デバイス」には 5 回線設定でき、それぞれを会社の電話の回線と共有できます。CTI リモート デバイスへの着信コールでは、コールが CTI リモート デバイスに設定または関連付けられたすべてのリモート接続先/サードパーティ製デバイスに転送されます。コールは、CTI リモート デバイス上の回線でアプリケーションに報告され、サードパーティ製デバイスに転送されたコールを表します。コール イベントは、他の通常のコールと同様に報告され、サードパーティ製デバイスに転送されたコールの状態を表します。
「Cisco Unified Client Services Framework(CSF)」デバイスは、Jabber クライアントから拡張モードで登録するようにも拡張されています。拡張モードでは、CSF デバイスは、CTI リモート デバイスとまったく同様に機能します。リモート接続先を設定して CTI リモート デバイスに関連付ける機能は、CSF デバイスにも拡張されました。
リモート接続先は、CTI リモート デバイスと CSF デバイスの CUCM 管理デバイス ページまたはリモート接続先ページ(新規追加および CTI リモート/CSF デバイスへの関連付け)、あるいは TSP アプリケーションからリモート接続先の追加、更新、削除機能を使用して設定できます。単一の CTI のリモート デバイスに設定できるリモート接続先の最大数は、CUCM 管理ユーザ ページのオーナーのユーザの最大リモート接続先設定によって異なります(デフォルトは 4)。
次に、このリリースでサポートされる CTI リモート デバイス上の機能を示します。
着信エンタープライズ コールの受信
コールの発信(DVO - オフィス経由のダイヤル)
コールの切断
保留/保留解除(再開/取得)
リダイレクト
DSS(デバイス ステート サーバ)、および DND(サイレント)と CPN(グローバル化された発呼側)
コール転送(話中、不在転送など)
転送と直接転送
会議と参加
リモート接続先の追加、更新、削除
URI ダイヤル
機能の詳細については、FFS(EDCS # 1048080)を参照してください。
この機能をサポートするために、CiscoTSP は、新しく追加された「CTI リモート デバイス」を列挙して公開し、「CTI リモート デバイス」に設定されたリモート接続先情報をアプリケーションに公開します。新しい回線タイプが CTI リモート デバイスに対して追加され、識別されたリモート デバイス ラインを使用して LINEDEVCAPS(LINEDEVCAPS::DevSpecific::dwLineTypeFlags = LINEDEVCAPSDEVSPECIFIC_REMOTEDEVICE (0x00000008))の Devspecific 部分でアプリケーションに公開されます。
これは、新しいリモート接続先の追加機能および「CTI リモート デバイス」または CSF デバイスに設定されている既存のリモート接続先の削除/更新機能をアプリケーションやユーザに提供します。CiscoTSP は、着信コールと発信コールをモニタおよび制御する機能をアプリケーションに提供します。
(注) | 注:この機能には、Cisco Jabber クライアントが必要であり、Jabber for Windows 9.1 でサポートすることを目的としたものです。 |
この機能をサポートするために次の新しいインターフェイスが追加されました。
CciscoLineDevSpecificAddRemoteDestination リモート接続先の追加
CciscoLineDevSpecificRemoveRemoteDestination リモート接続先を削除
CciscoLineDevSpecificUpdateRemoteDestination リモート接続先を更新
この機能をサポートするために次の新しいエラー コードが追加されました。
CTI リモートデバイスを参照してください。
Cisco Unified Communication Manager リリース 9.1 から、コールが CTI リモート デバイスにアソシエートされたリモート接続先に提供されると、一致するアプリケーション ダイヤル規則が桁分析の前に適用されます。CTI リモート デバイスのリモート接続先を追加または更新するアプリケーションが検証プロセスの一部である場合、アプリケーション ダイヤル ルールが桁分析の前に適用されます。
インターフェイスの変更はありません
N/A
Cisco Unified Communication Manager リリース 9.0 では、アプリケーション ダイヤル ルールは CTI リモート デバイスにアソシエートされたリモート接続先に適用されませんでした。
Cisco Unified Communication Manager リリース 9.1 アプリケーションは CTI リモート デバイスで lineGenerateDigits() API を呼び出すことができます。Cisco Unified Communication Manager リリース 9.1 ではアウトオブバンド DTMF のみサポートされています。
インターフェイスの変更はありません
N/A
これは新機能で、下位互換性があります。
Cisco Unified Communication Manager リリース 9.0 では、CSF デバイスにはリモート接続先を追加する機能がありました。Cisco Unified Communication Manager リリース 9.1 以降、CSF デバイスは拡張モードの CTI を CTI リモート デバイスとして登録できなくなり、CSF デバイスはリモート接続先を追加できなくなります。
インターフェイスの変更はありません
N/A
Cisco Unified Communication Manager リリース 9.0 からリリース 9.1 以降へアプリケーションをアップグレードすると、CSF デバイスに設定されたリモート接続先が削除されます。
Cisco Unified Communications Manager リリース 9.1 では、リモート接続先が CTI リモート デバイス上で追加または更新されたときに、そのリモート接続先の到達可能性を確認する拡張機能が CTI に追加されています。接続先が到達可能かどうかを確認するために、CTI は、CTI リモート デバイスに設定された再ルーティング CSS に基づいてデジタル分析を実行します。到達可能性の確認では、外部ダイヤル プレフィックス、CSS、およびルート パターンが正しく設定されていることを確認します。
接続先に到達できない場合、要求はエラー CTIERR_EXTEND_AND_CONNECT_DESTINATION_NOT_REACHABLE を返します。
エラー コード
LINEERR_REMOTE_DESTINATION_NOT_REACHABLE:アプリケーションがリモート接続先の追加または更新を試みて、リモート接続先に到達できなかった場合に返されます。
インターフェイスの変更はありません
N/A
Cisco Unified Communications Manager リリース 9.1 にアップグレードすると、下位互換性の問題が生じる場合があります。Unified Communications Manager リリース 9.0 では、接続先の到達可能性が確認されず、エラーは返されませんでした。
永続的接続または永続的コールとは、アクティブなカスタマー コールがない場合でも接続状態が維持される CTI リモート デバイスとリモート接続先の間のコールです。たとえば、1 日の最初に、Cisco Unified Communications Manager サーバが自宅にいる在宅勤務者に電話をかけて永続的接続を確立します。この接続は、アプリケーションがこのコールを切断するまで一日中アクティブ状態が維持されます。
永続的コールを作成するには、1 つ以上のリモート接続先が、CTI リモート デバイス上で設定されていてアクティブである必要があります。各リモート デバイスでは、一度に 1 つの永続的コールが許されます。永続的コール上では、パーク、保留、電話会議、転送などの機能の呼び出しは許可されません。
永続的コールが作成されると、アプリケーションがコールを切断するか最大通話時間タイマーが期限切れになるまで、その永続的コールは接続されたままになります。また、永続的コールは、リモート接続先がコールを切断するかリモート接続先がアクティブでなくなると切断されます。
リモート デバイスへのアクティブ コールが存在する場合、永続的コールを切断できません。そのため、アクティブなコールがある場合、そのコールが終了すると永続的コールはすぐに切断されます。
永続的接続では、通常のコールと異なり、メディア イベントが生成されません。アプリケーションは、承認された永続的コールに関する通知(LNECALLSTATE_ACCEPTED)を受信しないことがあります。この通知は、特定の電話網で使用されるトランクおよびゲートウェイのタイプによって異なる場合があります。
永続的コール機能によって一部の TAPI API が強化され、新しい API やエラー コードが導入されます。
(注) | この機能には下位互換性があり、既存のアプリケーションは、この機能の影響を受けません。 |
永続的コールを作成するには、TAPI の lineMakeCall 機能を使用します。関連データは、lpLineCallParams パラメータがポイントする LINECALLPARAMS 構造体に提供されます。Cisco TSP は、永続的コールの他の lineMakeCall パラメータをすべて無視します。
永続的コールでは、LINECALLPARAMS に次のデータが格納されます。
永続的コールをドロップまたは切断するには、標準の TAPI lineDrop 関数を使用します。hCall パラメータには、永続的コールを作成したときに lineMakeCall によって返される永続的コール ハンドル(HCALL)を指定する必要があります。
永続的コールのステータスが変化すると、アプリケーションは標準の TAPI LINE_CALLSTATE メッセージを受信します。永続的コールでは、dwParamas1 フィールドの新しいコール状態が次のように構成されます。
新しいビット定義 TSPCallAttribute_PersistentCall(0x00004000)が CiscoLineDevSpecificMsg.h ヘッダー ファイルの CallAttributeBitMask 列挙型に追加されます。永続的コールの場合、TAPI LINECALLINFO 構造体の Cisco TSP 拡張の CallAttributeBitMask フィールドで、対応するビットがオンになります。
この機能をサポートするために次の新しいエラー コードが追加されました。
エラー(Error) |
説明 |
---|---|
LINEERR_PERSISTENT_CALL_CREATE_FAILED |
永続的コールの作成に失敗しました。 |
LINEERR_PERSISTENT_CALL_ALREADY_EXISTS |
別の永続的コールがすでに存在するため、永続的コールを作成できません。 |
LINEERR_OPERATION_NOT_ALLOWED_ON_PERSISTENT_CALL |
パーク、保留、電話会議、転送などの機能の呼び出しは、永続的コールでは許可されません。 |
LINEERR_PERSISTENT_CALL_DROP_FAILED_CALL_ACTIVE |
カスタマー コールがアクティブなときに、永続的コールを切断しようとしました。 |
LINEERR_NO_PERSISTENT_CALL_EXISTS |
永続的コールが存在しないデバイスに対してアナウンス コールを作成しようとしました。 |
LINEERR_PERSISTENT_CALL_NOT_ESTABLISHED |
永続的コールの設定中にアナウンス コールを作成しようとしました。 |
LINEERR_OPERATION_NOT_AVAILABLE_IN_CURRENT_STATE |
要求された操作は現在のコール状態では許可されていません。 |
永続的接続の使用例を参照してください。
この機能拡張には下位互換性があり、既存のアプリケーションは、この機能拡張の影響を受けません。
Cisco Extend and Connect はリモート接続先にアナウンスを再生する機能で強化されます。アナウンスを再生するには、アプリケーションが特殊なタイプのコール(アナウンス コール)を作成し、再生されるアナウンスを特定します。
アナウンスは既存の永続的コールでリモート接続先にのみ再生できます。Unified Communications Manager にアップロードされたアナウンスのみ再生できます。
アプリケーションには、アナウンスが LINE_DEVSPECIFIC イベント、SLDSMT_ANNOUNCEMENT_STARTED で開始されたことが通知されます。
アプリケーションには、アナウンスが LINE_DEVSPECIFIC イベント、SLDSMT_ANNOUNCEMENT_ENDED で停止されたことが通知されます。
TAPI の lineMakeCall 関数は、アナウンス コールの作成に使用されます。関連データは lpLineCallParams パラメータによってポイントされている LINECALLPARAMS 構造体で提供されます。CiscoTSP は、アナウンス コール時にその他の lineMakeCall パラメータをすべて無視します。
アナウンス コール時には、次のデータが LINECALLPARAMS で提供されます。
標準の TAPI lineDrop 関数は、アナウンス コールをドロップ(接続解除)します。hCall パラメータは、アナウンス コール作成時に lineMakeCall により返されるアナウンス コール ハンドル(HCALL)を指定します。
アナウンス コールの状態が変化すると、アプリケーションは標準の TAPI LINE_CALLSTATE メッセージを受信します。アナウンス コールについては、dwParams1 フィールドの新しいコール状態の構築は次のとおりです。
新しいビット定義、TSPCallAttribute_AnnouncementCall (0x00008000) は CiscoLineDevSpecificMsg.h ヘッダー ファイルの CallAttributeBitMask の列挙型に追加されます。アナウンス コールについては、対応するビットが TAPI LINECALLINFO 構造体の Cisco TSP 拡張の CallAttributeBitMask フィールドでオンになっています。
Cisco Unified Communications Manager リリース 10.01 以降では、アプリケーションは lineMakeCall を使用して、永続的コールまたはアナウンス コールを作成できます。永続的コールまたはアナウンス コールについては、関連データは lpLineCallParams パラメータによってポイントされている LINECALLPARAMS 構造体で提供されます。その他すべての lineMakeCall パラメータは、この場合は無視されます。
アナウンス コールを参照してください。
この強化は下位互換性があり、既存のアプリケーションはこの強化の導入による影響を受けません。
CUCM 10.0 では、既存の「Cisco Extend and Connect」機能にリモート接続先の番号照合のサポートが含まれます。CTI リモート デバイス(CTI RD)のリモート接続先として設定された番号にユーザが直接コールし、そのリモート接続先がアクティブである場合、コールは CTI リモート デバイスに対して要求され、最終的にはリモート接続先に着信します。着信側は、CTI RD としてアプリケーションに提供されます。アクティブなリモート接続先がセットされていない場合、ユーザがリモート接続先番号をコールすると、発信者とリモート接続先との間の直接コールが発生します。このシナリオは、エンタープライズ ディレクトリ番号にコールするリモート接続先にも適用されます。リモート接続先がアクティブに設定されている場合、アプリケーションから見ると、CTI RD が会社のダイヤル番号へのコールを開始するように見えます。アクティブなリモート接続先が設定されていない場合、リモート接続先が会社のダイヤル番号へのコールすると、そのコールはリモート接続先と企業のダイヤル番号との間の直接コールになります。
リモート接続先番号との間のコールの場合、CTI RD で許可されている既存の全機能を実行できます。
この機能には、インターフェイスの変更はありません。
「NuRD(リモート接続先の番号照合)のサポート」を参照してください。
「Cisco Extend and Connect」機能には、モビリティ機能との相互運用が含まれています。ユーザは、CTI リモート デバイス(CTI RD)とリモート接続先プロファイル(RDP)の間で共有されるリモート接続先を指定できるようになりました。同じユーザに CTI RD と RDP の両方が設定され、アプリケーションがアクティブな(アクティブ RD がセットされた)場合、まず CTI RD がコールを処理し、それからコールを RDP に提供します。アプリケーションがアクティブでない場合、まず RDP がコールを処理しますが、CTI RD へコールを提供しません。あるユーザに CTI RD だけが設定されている場合、既存の「Cisco Extend and Connect」機能のリモート接続先についての動作に変更はありません。あるユーザに RDP だけが設定されている場合、デバイスが CTI 制御可能でないため、アプリケーションによるサポートはありません。
この機能には、インターフェイスの変更はありません。
この機能の新しい使用例はありません。リモート接続先の追加、更新、削除が CTIRD 用に追加され、アプリケーションやユーザから変更せずに適用できます。
この機能に下位互換性問題はありません。
Cisco Unified Communications Manager 10.0(1) 以降、「CTI Rd コール転送」という新機能によって、アクティブなリモート接続先が設定されていない場合に、着信コールが CTI リモート デバイス上で設定されたすべてのリモート接続先にいつ転送されるかユーザは制御できます。
新しいチェックボックス [クライアントが接続されていないときすべてのリモート接続先にコールをルーティング(Route calls to all remote destinations when client is not connected)] が Cisco Unified Communications Manager のデバイス ウィンドウに追加されています。このチェックボックスは、アクティブなリモート接続先が設定されていない場合に、通話をすべてのリモート接続先へルーティングするかどうかを決定します。
[クライアントが接続されていないときすべてのリモート接続先にコールをルーティング(Route calls to all remote destinations when client is not connected)] チェックボックスが有効で、アクティブなリモート接続先が設定されていない場合、コールはすべてのリモート接続先にルーティングされます。このチェックボックスが無効で、アクティブなリモート接続先が設定されていない場合、コールは CTI リモートデバイスで User_Busy エラーにより接続解除されます。
アクティブなリモート接続先が設定されたシナリオでは、[クライアントが接続されていないときすべてのリモート接続先にコールをルーティング(Route calls to all remote destinations when client is not connected)] チェックボックスが有効か無効かに関係なく、コールは常時アクティブなリモート接続先にルーティングされます。
この機能には、インターフェイスの変更はありません。
CTI RD コール転送を参照してください。
この機能には、下位互換性の問題はありません。
CTI ビデオ サポート機能により、TAPI アプリケーションは、回線デバイスのマルチメディア機能を取得できます。デバイスをモニタするアプリケーションはこの情報を使用して、ビデオ対応デバイスにビデオ コールを応答したりルーティングしたりします。
TAPI はアプリケーションが拡張バージョンが 0x000D0000 以降の TSPI_LineGetDevCaps () API をこれらの回線デバイスで発行する場合に linedevcaps の Devspecific データの新しい構造体 DeviceMultiMediaCapability を提供するものとします。Cisco TSP は param1=LPCT_DEVICE_MULTIMEDIACAP_INFO または PPCT_DEVICE_MULTIMEDIACAP_INFO を指定した SLDSMT_LINE_PROPERTY_CHANGED または CPDSMT_PHONE_PROPERTY_CHANGED_EVENT を通知し、マルチメディア機能の情報の変更を報告します。
新しい構造体 DeviceCallMultiMediaCapInfo は CiscoLineDevSpecificMsg.h 下で導入されます。これは LineGetCallInfo の devspecific データで提供される発信者および着信側のマルチメディア機能に関する情報を提供します。
同様に、コールの発信者/着信側のビデオ機能が変更された場合、TSP は param1= SLDSMT_LINECALLINFO_DEVSPECIFICDATA および param2= SLDST_DEVICE_VIDEO_CAP_INFO を指定した LINE_CALLDEVSPECIFIC を通知し、コールのマルチメディア機能の情報を報告します。
また、LineCallinfo の devspecific データには、有効な情報で DeviceMultiMediaCapInfo のフィールドを示す、2 つの新しいフィールド CallingPartyMultiMediaCapBitMask と CalledPartyMultiMediaCapBitMask が含まれています。
アプリケーションが 1 台のビデオ対応電話間でビデオ コールを発信すると、TSP は param1=SLDSMT_MULTIMEDIA_STREAMSDATA を指定した LINE_CALLDEVSPECIFIC イベントを通知し、コールのマルチメディア ストリーム情報を報告します。コールのマルチメディア ストリーム情報は、アプリケーションが拡張バージョンが 0x000D0000 以降の TSPI_LineGetCallInfo() API を発行する場合に、(VideoStreamInfo 構造体の一部として)linecallinfo の Devspecific データで提供されます。
Device | 初期デバイス マルチメディア機能をサポート | 動的なビデオ機能の変更をサポート | コール情報(LineGetCallInfo)の発信者および着信側マルチメディア機能を報告 | マルチメディア ストリーム情報をサポート |
---|---|---|---|---|
8945(SIP) | ○ | ○ | ○ | ○ |
8945(SCCP) | ○ | ○ | ○ | [いいえ(No)] |
9951、9971(SIP) | ○ | ○ | ○ | ○ |
EX60/90(SIP) | ○ | 該当なし | ○ | ○ |
CTS 500-32(SIP) | ○ | 該当なし | ○ | ○ |
Jabber(CSF/softphone モード)(SIP) | ○ | ○ | ○ | [いいえ(No)] |
CTI RoutePoint(SCCP) | 該当なし | 該当なし | [はい(Yes)] | [いいえ(No)] |
CTI ポート(SCCP) | 該当なし | 該当なし | [はい(Yes)] | [いいえ(No)] |
その他のすべての電話機 | 該当なし | 該当なし | [はい(Yes)] | [いいえ(No)] |
サポートされる機能(同一クラスタ内)
サポートされる機能(クラスタ間)
制限事項
ビデオ機能とマルチメディア情報を参照してください。
この機能には下位互換性はありません。
共通デバイス設定が関連付けられていないデバイスのデフォルト CTI IP アドレッシング モードを設定できる新しい CTIManager サービス パラメータ、[デバイスの IP アドレッシング モード(IP Addressing Mode for Devices)] を追加しました。
Cisco TAPI はこのパラメータの値を、TAPI LINEDEVCAPS 構造のデバイス固有の拡張機能のアプリケーションに伝えます。アプリケーションが共通デバイス設定のないデバイスの lineGetDevCaps() メソッドを呼び出すと、Cisco TAPI は dwLineDevCapsIPAddressingMode フィールドの値を返します。デフォルトで、このパラメータは IPv4 と IPv6 の両方のモードに対応する設定になります(IPAddress_IPv4_IPv6)。
(注) | 個々の CTI デバイスの場合、そのデバイスに関連する共通デバイス設定があると、共通デバイス設定の IP アドレッシングモード設定は、[デバイスの IP アドレッシング モード(IP Addressing Mode for Devices)] の値をオーバーライドします。 |
デバイス ステート サーバ機能は、デバイスのすべての回線の累積状態を提供します。アプリケーションには、PHONE_DEVSPECIFIC イベントと LINE_DEVSPECIFIC イベントを通じてデバイス ステータスが通知されます。
デバイス ステート サーバのサポートを有効にするアプリケーションでは、lineDevSpecific SLDST_SET_STATUS_MESSAGES 要求および PhoneDevSpecific CPDST_SET_DEVICE_STATUS_MESSAGES 要求を使用して、DEVSPECIFIC_DEVICE_STATE メッセージ フラグと DEVSPECIFIC_DEVICE_STATE_STATUS_ メッセージ フラグをそれぞれ設定する必要があります。
Cisco TSP は CTI から DEVICE_STATE イベントを受信すると、PHONE_DEVSPECIFIC イベントおよび LINE_DEVSPECIFIC イベントを使用してデバイスの全回線の累積状態についてアプリケーションに通知します。
LINE_DEVSPECIFIC イベントおよび PHONE_DEVSPECIFIC イベントのデバイス ステータスは次のいずれかです。
enum lineDeviceState{ lineDeviceState_UNKNOWN = 0, lineDeviceState_ACTIVE = 1, lineDeviceState_ALERTING = 2, lineDeviceState_HELD = 3, lineDeviceState_WHISPER = 4, lineDeviceState_IDLE = 5 }; enum PhoneDeviceState{ PhoneDeviceState_UNKNOWN = 0, PhoneDeviceState_ACTIVE = 1, PhoneDeviceState_ALERTING = 2, PhoneDeviceState_HELD = 3, PhoneDeviceState_WHISPER = 4, PhoneDeviceState_IDLE = 5 };
この機能は、デバイスまたは電話機の全回線の累積状態をアプリケーションに提供します。イベントの提供基準は次のとおりです。
IDLE
デバイスのすべての回線が IDLE のとき、デバイス状態は IDLE と見なされ、対応するイベントが対象のアプリケーションに送信されます。
ACTIVE
デバイスのいずれかの回線に ACTIVE(コール状態は LINECALLSTATE_DIALTONE、LINECALLSTATE_DIALING、LINECALLSTATE_PROCEEDING、LINECALLSTATE_RINGBACK、および LINECALLSTATE_DISCONNECTED)コールがあると、デバイス状態は ACTIVE と見なされ、対応するイベントが対象のアプリケーションに送信されます。
ALERTING
デバイスのどれの回線にも ACTIVE コールがなく、少なくとも 1 回線に ALERTING(コール状態は LINECALLSTATE_OFFERING および LINECALLSTATE_ACCEPTED)コールがある場合、デバイス状態は ALERTING と見なされ、対応するイベントが対象のアプリケーションに送信されます。
HELD
デバイスのどの回線にも ACTIVE コールまたは ALERTING コールがなく、少なくとも 1 回線に HELD コールがある場合、デバイス状態は HELD と見なされ、対応するイベントが対象のアプリケーションに送信されます。
WHISPER
デバイスのどの回線にも ACTIVE コール、ALERTING コール、または HELD コールがなく、少なくとも 1 回線にインターコム コールがある場合、デバイス状態は WHISPER と見なされ、対応するイベントが対象のアプリケーションに送信されます。
(注) | ACTIVE 状態は、ALERTING 状態、HELD 状態、および IDLE 状態よりも優先されます。 ALERTING 状態は、HELD 状態および IDLE 状態よりも優先されます。 HELD 状態は、IDLE 状態よりも優先されます。 |
(注) | LineDevSpecific イベントで、デバイスの任意の回線に関するデバイス状態を提示するには、lineDevSpecific SLDST_SET_STATUS_MESSAGES 要求で、その回線の DEVSPECIFIC_DEVICE_STATE_STATUS_message フラグをオンにします。 |
Cisco Unified Communications Manager には、[Direct Transfer(直接転送)] ソフトキーがあります。このソフトキーを押すと、1 つの確立済みコールの相手側が、別の確立済みコールの相手側に転送され、この機能を呼び出したユーザが両方のコールから切断されます。確立済みコールとは、保留状態または接続状態のコールのことです。"直接転送"機能では、コンサルト コールは開始されず、アクティブ コールは保留状態に変更されません。
TAPI アプリケーションでは、確立済みの 2 つのコールに対し、lineCompleteTransfer() 関数で、"直接転送"機能を呼び出すことができます。lineSetupTransfer() 関数を使用して、これら 2 つのコールを最初に確立する必要はありません。
回線をまたいで直接転送機能を使用すると、アプリケーションはデバイスに設定されている複数の回線間で直接コールを転送できます。回線間でコールを直接転送する場合、アプリケーションは両方の回線をモニタします。
新しい LineDevSpecific 拡張である CCiscoLineDevSpecificDirectTransfer が追加され、複数回線間または同一回線上でコールを直接転送できるようになっています。CCiscoLineDevSpecificDirectTransfer を使用するには、0x00090000 拡張をネゴシエートする必要があります。
直接転送を参照してください。
CTI リモートデバイスを参照してください。
ディレクトリ内でユーザ制御デバイス リストにデバイスが追加されたり、リストからデバイスが削除されると、Cisco Unified TSP から通知イベントが送信されます。Cisco Unified Communications Manager Administration からユーザが削除されると、Cisco Unified TSP はイベントを送信します。
ユーザ制御リストにデバイスが追加されると、Cisco Unified TSP から LINE_CREATE メッセージまたは PHONE_CREATE メッセージが送信されます。
ユーザ制御リストからデバイスが削除された場合、またはデータベースからデバイスが削除された場合は、LINE_REMOVE メッセージまたは PHONE_REMOVE メッセージが送信されます。
システム管理者によって現在のユーザが削除されると、オープンされていた回線および電話機ごとに、Cisco Unified TSP によって LINE_CLOSE メッセージおよび PHONE_CLOSE メッセージが生成されます。その後、すべての回線と電話機に関して、LINE_REMOVE メッセージおよび PHONE_REMOVE メッセージが送信されます。
サイレント(DND)機能を使用すると、ユーザが電話機から離れている場合や、着信コールに応答したくない場合に、電話機をサイレント状態に切り替えることができます。この機能を有効または無効にするには、電話機の DND ソフトキーを使用します。
Cisco Unified Communications Manager ユーザ ウィンドウでは、DND オプションの DNR(呼出音オフ)を選択できます。
Cisco TSP では、DND 機能に関連して電話機の次のオプションを設定できます。
DND オプション:[なし(None)]/[呼出音オフ(Ringer Off)]
DND 着信呼警告:[ビープ音のみ(Beep only)]/[フラッシュのみ(Flash only/)]/[無効(Disable)]
DND(サイレント)タイマー:0 分 ~ 120 分DND(サイレント)がアクティブであることをユーザに知らせる時間(分単位)を指定
DND の有効化と無効化
Cisco TSP は、拡張バージョン 8.0(0x00080000)以上をネゴシエートする TAPI アプリケーションに対しても DND(サイレント)機能をサポートします。
アプリケーションから実行できる操作は、デバイス上で DND 機能を有効または無効にすることだけです。TAPI アプリケーションから DND 機能を有効または無効にするには、Cisco TSP の lineDevSpecificFeature API を使用します。
DND の設定または状態が変更されると、Cisco TSP からアプリケーションに LINE_DEVSPECIFICFEATURE メッセージが送信されます。この変更通知を受信するには、lineDevSpecific SLDST_SET_STATUS_MESSAGES 要求で DEVSPECIFIC_DONOTDISTURB_CHANGED メッセージ フラグを有効にする必要があります。
サイレント(DND)機能拡張により、コールの拒否がサポートされるようになりました。Do Not Disturb–Reject(DND–R)機能拡張によって、ユーザは必要に応じてコールを拒否することができます。Cisco Unified Communications Manager Release 7.0(1) よりも前のバージョンでは、DND は [呼出音オフ(Ringer Off)] オプションだけが使用可能でした。DND が設定されている場合、電話は鳴りませんが、コールは表示され続けます。
DND–R を有効にするには、Cisco Unified CM の管理の電話のページにアクセスするか、ユーザがその電話上で有効にします。
しかし、そのコールに緊急プライオリティが設定されている場合は、DND–R オプションが選択されていても着信コールが表示されます。これによって、緊急コールを逃すことはなくなります。
機能プライオリティは enum type で説明し定義して、コールの発信や既存コールのリダイレクトを行います。プライオリティは次のように定義されています。
enum CiscoDoNotDisturbFeaturePriority { CallPriority_NORMAL = 1 CallPriority_URGENT = 2 CallPriority_EMERGENCY = 3 };
機能優先順位では、DevSpecific データの一部として LineMakeCall を使用します。現在、DevSpecific データでは、LineMakeCall に次の構造体をサポートしています。
typedef struct LineParams { DWORD FeaturePriority; } LINE_PARAMS;
Cisco LineDevSpecific の新しい機能拡張であるタイプ SLDST_REDIRECT_WITH_FEATURE_PRIORITY の CCiscoLineRedirectWithFeaturePriority では、機能優先順位によるリダイレクト コールをサポートしています。
また、共有回線のシナリオで、回線の 1 つで DND–R が有効になっていて [リモートで使用中(Remote In Use)] が TRUE の場合、CONNECTED INACTIVE のマークが付きます。
lineMakeCall および機能プライオリティを使用したリダイレクト を参照してください。
Do Not Disturb-Rejectを参照してください。
Drop-Any-Party 機能を使用すると、アプリケーションはアドホック会議からのすべてのコールを切断できます。この機能は現在、電話インターフェイスでサポートされています。アプリケーションは LineRemoveFromConference 関数を使用してコールを会議から切断します。コールが会議から切断されると、TSP はコール状態の変更原因として CtiDropConferee を受け取り、これをデフォルトの原因として TAPI に送出します。
lineRemoveFromConferenceを参照してください。
任意の通話者のドロップを参照してください。
アーリー オファー機能を使用すると、発信側エンドポイントのメディア機能とメディア ポート情報が使用可能である場合に、SIP トランクで MTP を使用せずにアーリー オファー発信コールをサポートできます。アーリー オファーでメディア ポート情報が使用できないエンドポイント(H323 スロー スタート コール、ディレイド オファー SIP コール、従来の SCCP 電話機など)の場合、Cisco Unified Communications Manager は MTP を割り当ててオファーを行います。つまり、Unified CM は、必要な場合だけ MTP を割り当てます。
アーリー オファー機能をサポートするため、Cisco TSP では CCiscoLineDevSpecific 拡張(CCiscoLineDevSpecificEnableFeatureSupport)が導入され、アプリケーションでアーリー オファー機能を有効または無効にできるようになりました。この DevSpecific タイプは汎用であり、将来追加される機能のサポートに使用できます。
CTI ポートまたはルート ポイントの登録は、次のとおりです。
GET IP および PORT EVENT は、発信コール上で、アーリー オファー サポートを有効にして登録された CTI ポートまたはルート ポイントに通知されます。発信コールがアーリー オファー サポート付きの SIP トランクを経由すると、TSP は Param1 = SLDSMT_RTP_GET_IP_PORT および Param2 = IPAddressing Mode を示す LINE_DEVSPECIFIC イベントと SetRTP ビット情報(LSB からの 9 番めのビット)を通知します。
dwParam2 = 0x00000xyy。ここで、各ビットの意味は次のとおりです。
x(LSB から 9 番めのビット):SetRTPInfo(1 はアプリケーションが RTP 情報を設定する必要があることを示し、0 はアプリケーションが RTP 情報を設定する必要がないことを示します)。
yy(8 ビット):IPAddressing モード。
アーリー オファー付きで動的に登録された CTI ポートまたはルート ポイントの場合:この通知に関しては、アプリケーションは、既存の LineDevspecific タイプ(CCiscoLineDevSpecificSetRTPParamsForCall)を使用して、通知された IPAddressing モードの IP およびポート情報を示す RTP 情報を設定する必要があります。アプリケーションがすでに GetIP and Port 通知(SLDSMT_RTP_GET_IP_PORT)に関する情報を設定している場合、アプリケーションでは Open Logical Channel 通知で RTP 情報を設定する必要はありません。
静的に登録された CTI ポートの場合:この通知に対して、アプリケーションは登録に使用するポートをオープンし、予約する必要があります。
GetIP and Port 通知(SLDSMT_RTP_GET_IP_PORT)を受信するには、アプリケーションで lineDevSpecific SLDST_SET_STATUS_MESSAGES 要求を使用して DEVSPECIFIC_GET_IP_PORT メッセージ フラグを設定する必要があります。
TAPI は、IP アドレッシング機能とともに、OpenLogical Channel 通知(LINE_DEVSPECIFIC イベントの dwParam1 = SLDSMT_OPEN_LOGICAL_CHANNEL)の dwParam2 に setRTP 情報を設定します。アプリケーションはこの情報を使用して、RTP 情報を設定する必要があるかどうかを判断します。
dwParam2 = 0x0000xxyy。ここで、各ビットの意味は次のとおりです。
xx:SetRTPInfo(1 はアプリケーションが RTP 情報を設定する必要があることを示し、0 はアプリケーションが RTP 情報を設定する必要がないことを示します)。
yy:IPAddressing 機能。
アプリケーションがアーリー オファー サポートなしで動的または静的に CTI ポートまたはルート ポイントを登録しようとした場合に、CTI ポートがすでに他のアプリケーションによってアーリー オファー サポート付きで動的または静的に登録されていると、TSP は新しいエラー コード(LINEERR_REGISTER_GETPORT_SUPPORT_MISMATCH)を返します。
アーリー オファー サポート付きで登録された CTI ポートでのアーリー オファー コールについては、他の通話者が発呼側の IP およびポート情報を持っている場合、(アーリー オファー付きで登録された)CTI ポートにメディア イベントが報告されるよりも早く、その通話者がメディアの送信を開始します。
このアーリー メディアにより、またはアプリケーションへのメディア受信イベントの通知における時間的な差によって、Wave Driver は初期に送信されるデータを受信できません。これは、現在の Wave Driver(レガシーおよび新しい Cisco Wave Driver)はメディア イベントがアプリケーションに通知された後でのみ、ポートのオープンをサポートしてデータの受信を開始するためです。
早期に送信されるデータをキャプチャするには、受信側のポートは、GET_IP_PORT イベントの後にオープンされ、データのバッファリングを行う必要があります。新しい Wave Driver およびレガシー Wave Driver でポートをオープンするために現在サポートされている API には、CODEC およびその他のサポートされている情報(DSCP、SRTP 情報、および Silence Type)が必要です。ただし、アーリー オファーの場合、この情報は GET_IP_PORT イベントで使用できません。ポートのオープン、バッファリングの開始、その他のメディア エンドポイント関連情報(CODEC、DSCP、SRTP 情報、Silence Type)によるエンドポイント更新のために新しい API を追加する必要があります。
アーリー オファー コールのアーリー メディア データをキャプチャするために、新しい Wave Driver に次の API を追加しました。
EpStreamOpen():ポートをオープンして、着信データのバッファリングを開始します。
EpUpdateById():メディア エンドポイント データ情報(CODEC、DSCP、SRTP 情報、および Silence Type)を更新します。
更新に成功したときに True、または失敗したときに False を返します。EpApiGetLastError を呼び出すことにより、特定のエラー コードを取得できます。
EpStreamStart() API を使用してストリームがすでに開始されている場合、EpUpdateById() 要求はエラー EP_ERR_TOAPP_INVALID_STATE で失敗します。
EpStreamOpen() API を使用してポートをオープンしている場合、EpUpdateByID() によって、アドレスとポートを除くメディア エンドポイント関連のデータ情報が更新されます。
ストリームが開始されたときに、オープンされたソケットに実際に使用されているポートが LocalAddrInfo と一致しない場合、要求はエラー EP_ERR_ADDR_MISMATCH で失敗します。
(注) | アプリケーションでは、新たに追加されたこれらの API を使用して、アーリー オファー コールのアーリー メディア データをキャプチャする必要があります。 |
次の図のメッセージ フローを、ステップ 1 と 2 で説明します。
TAPI を初期化し、使用可能な回線デバイスの LINEINFO を取得して、Cisco RTP Library 機能を使用できるデバイスを検出します。
特定の回線デバイスに関連付けられたメディア デバイス ID を取得します。
次の図のメッセージ フローを、ステップ 3 ~ 6 で説明します。
RTP Library を初期化します。
Cisco lineDevSpecific 拡張(CCiscoLineDevSpecificSetStatusMsgs)を使用して、メディア ストリームと、関連するデバイスの GetIP および Port イベントを登録します。
lineDevSpecific 拡張(CCiscoLineDevSpecificEnableFeatureSupport)を使用して、その回線またはデバイスでのアーリー オファー機能のサポートを有効にします。
GetIP および Port イベントがアプリケーションに通知され、アーリー オファー コールの通知を行います。
次の図のメッセージ フローを、ステップ 7 ~ 8 で説明します。
データ受信用のメディア エンド ポイントを作成します。
データ受信用に作成したメディア エンド ポイントのストリーム ハンドルを取得します。
受信側でポートをオープンし、データのバッファリングを開始します。
メディア イベントのモニタリングを開始します。
*** hEpRecv = ストリーム受信用のストリーム ハンドル
次の図のメッセージ フローを、ステップ 11 ~ 17 で説明します。
データ送信用のメディア エンド ポイントを作成します。
出力ストリーム ハンドルを取得します。
データ ストリーミングを開始します。
メディア イベントで使用できる CODEC およびその他の情報を使用して、オープンされているメディア エンド ポイントを更新します。
データを送受信します。
データ ストリーミングを停止し、エンド ポイントを閉じます。
プログラムを終了する前に、EpAPI を閉じます。
(注) | この機能をサポートするには、アプリケーションが回線拡張バージョン 0x000B0000 以上でネゴシエートする必要があります。 |
Early Offer(アーリー オファー)、機能の有効化、IP およびポート イベントの取得、ステータス メッセージの設定、および論理チャネル オープン イベントを参照してください。
Early Offer(アーリー オファー)を参照してください。
End-to-End コール トレースは、複数のシスコ音声製品(Cisco Unified Communications Manager、Cisco IOS Gateway、および Cisco Call Center 製品など)を通過するコールをトレースすることができます。
System Call Tracing ツールという新しいツールが開発され、すべての音声プラットフォームからコール記録を収集して、特定のコールを追跡するとともに、コール障害やその他の問題点を解決します。
このツールは、発信側番号、着信側番号、およびタイムスタンプを使用することによって、アクセス可能なすべての音声製品から少なくとも 1 つのコール記録を検索します。System Call Tracing ツールは、単一のコール記録をもとに、それが通過したすべての音声製品でそのコールをトレースできます。
LINECALLINFO::DEVSPECIFIC は、TSP の一意のコール参照値 ID を含む様に修正されます。詳細については、LINECALLINFOを参照してください。
エンドツーエンド コール トレースを参照してください。
この機能により、EnergyWise が有効なシステムに、電話機で参加できます。電話機の電力使用率が、電話機から EnergyWise 準拠スイッチに通知され、カスタマーの建物内の電力のトラッキングと制御ができます。電話機は、消費電力がきわめて低いオフ モードなどの、代替電力低減モードを提供します。Cisco Unified Communications Manager 管理者は、Cisco Unified CM の管理ページのベンダー固有の設定を使用して、電話機の電力状態を設定し、排他的に管理します。
EnergyWise スイッチとのネゴシエーション後に電話機の電源オフ時間になると、Cisco Unified CM から登録解除し、Deep Sleep/PowerSavePlus モードに移行します。電話機は、Deep Sleep モードが設定した電源オン時間に達すると自動的に Cisco Unified CM に再登録します。
ただし、Cisco Unified IP Phones 9900 および 6900 シリーズの電話機の場合、電話機の選択キーを押して電話機を Deep Sleep/PowerSavePlus モードから復帰させますが、Cisco Unified IP Phones 7900 シリーズの電話機を、Deep Sleep 中に Cisco Unified CM に登録する方法はありません。これが、Cisco Unified IP Phones 7900 シリーズの電話機が持つ制限です。Deep Sleep モードは、Cisco Unified CM のデバイス ページで設定できます。電話機の Deep Sleep モードを、実際の電源オフの時間よりも 10 分以上前に設定すると、スイッチと電話機間で情報を同期できます。
電源オフのアイドル タイマーは、電話機に物理的な操作があった場合にのみ有効になります。たとえば、EnergyWise が設定された電話機に、Deep Sleep 移行中にコールがあり、ユーザがアプリケーションからコールを切断すると、電源オフのアイドル タイマーが 10 分にデフォルト設定されますが、ユーザが電話機から手動でコールを切断すると、電源オフのアイドル タイマーは Cisco Unified CM のデバイス ページで設定された値をとります。
DeepSleep に移行した際に電話機が登録解除し、電話機が適切な拡張バージョン 0x000B0000 以上で正常にネゴシエートした場合、TAPI は dwparam1 = PHONESTATE_SUSPEND の PHONE_STATE メッセージと、dwParam2 に EnergyWisePowerSavePlus 理由を提供します。
DeepSleep に移行した際に電話機が登録解除し、電話機が適切な拡張バージョン 0x000B0000 以上で正常にネゴシエートした場合、TAPI は dwparam1 = LINEDEVSTATE_OUTOFSERVICE の LINE_LINEDEVSTATE メッセージと、dwparam2 に EnergyWisePowerSavePlus 理由を提供します。
この機能の一部として、TAPI は電話機が登録解除し、適切な拡張バージョン 0x000B0000 以上で正常にネゴシエートした場合、すべてのアウト オブ サービスの理由コードを dwParam2 の PHONESTATE_SUSPEND および LINEDEVSTATE_OUTOFSERVICE に公開します。
TAPI は、CiscoLineDevSpecificMsg.h の新しい enum CiscoLineDevStateOutOfServiceReason
および CiscoPhoneDevSpecificMsg.h の enum CiscoPhoneStateOutOfServiceReason を定義します。
New Enum under CiscoLineDevSpecificMsg.h enum CiscoLineDevStateOutOfServiceReason { CiscoLineDevStateOutOfServiceReason_Unknown = 0x00000000, CiscoLineDevStateOutOfServiceReason_CallManagerFailure = 0x00000001, CiscoLineDevStateOutOfServiceReason_ReHomeToHigherPriorityCM = 0x00000002, CiscoLineDevStateOutOfServiceReason_NoCallManagerAvailable = 0x00000003, CiscoLineDevStateOutOfServiceReason_DeviceFailure = 0x00000004, CiscoLineDevStateOutOfServiceReason_DeviceUnregistered = 0x00000005, CiscoLineDevStateOutOfServiceReason_EnergyWisePowerSavePlus = 0x00000006, CiscoLineDevStateOutOfServiceReason_CtiLinkFailure = 0x00000101 }; New Enum under CiscoPhoneDevSpecificMsg.h enum CiscoPhoneStateOutOfServiceReason { CiscoPhoneStateOutOfServiceReason_Unknown = 0x00000000, CiscoPhoneStateOutOfServiceReason_CallManagerFailure = 0x00000001, CiscoPhoneStateOutOfServiceReason_ReHomeToHigherPriorityCM = 0x00000002, CiscoPhoneStateOutOfServiceReason_NoCallManagerAvailable = 0x00000003, CiscoPhoneStateOutOfServiceReason_DeviceFailure = 0x00000004, CiscoPhoneStateOutOfServiceReason_DeviceUnregistered = 0x00000005, CiscoPhoneStateOutOfServiceReason_EnergyWisePowerSavePlus = 0x00000006, CiscoPhoneStateOutOfServiceReason_CtiLinkFailure = 0x00000101 };
を参照してください。 EnergyWise Deep Sleep モードの使用例
この機能は下位互換性があります。
エクステンション モビリティは、ユーザが電話機にログインとログアウトできる Cisco Unified Communications Manager 機能です。Cisco Extension Mobility は、ユーザがログインすると、そのユーザのデバイス プロファイル(回線、スピード ダイヤル番号など)を電話機に読み込みます。
Cisco Unified TSP は、デバイスにログインしたユーザを Cisco Unified TSP ユーザとして認識します。
Cisco Unified Communications Manager Administration でユーザをコントローラのリストに関連付けることができます。
Cisco Unified TSP ユーザがデバイスにログインすると、そのユーザの Cisco Extension Mobility プロファイルに登録されている回線が電話機に読み込まれ、それまで電話機にあった回線は削除されます。Cisco Unified TSP ユーザの制御対象デバイス リストにそのデバイスが登録されていない場合は、アプリケーションに PHONE_CREATE メッセージまたは LINE_CREATE メッセージが送信されます。制御対象デバイス リストにそのデバイスが登録されている場合は、追加された回線(ログインによって読み込まれた回線)に対して LINE_CREATE が通知され、削除された回線に対して LINE_REMOVE が通知されます。
ユーザがログアウトすると、元の回線へ復元されます。制御対象外デバイスの場合には、アプリケーションによって PHONE_REMOVE メッセージまたは LINE_REMOVE メッセージが通知されます。制御対象デバイスの場合には、追加された回線(ログアウトによって復元された回線)に対して LINE_CREATE が通知され、削除された回線に対して LINE_REMOVE が通知されます。
クラスタ間のエクステンション モビリティを使用すると、特定のクラスタにプロビジョニングされたユーザが、他のクラスタの IP フォンにログインできます。
この機能を使用するために、Cisco TSP のユーザへの関連付けデバイスには、通常のデバイスだけではなく、エクステンション モビリティに使用するデバイス プロファイルも関連付けることができます。制御リストにこのプロファイルを追加し、クラスタ間のエクステンション モビリティ ユーザが、クラスタ内またはクラスタ外のデバイスにログインまたはログアウトすると、Cisco TSP がアプリケーションに対し、必要な PHONE_CREATE/LINE_CREATE および PHONE_REMOVE/LINE_REMOVE イベントを通知します。
クラスタ間のエクステンション モビリティ(Extension Mobility Cross Cluster)を参照してください。
エクステンション モビリティ(EM)機能のサポートにより、Cisco Unified TSP では、EM ログイン/ログアウトによる、TAPI の LINE_CREATE/LINE_REMOVE を利用して、回線デバイスの動的な作成および削除を実装することができます。TAPI の目的上、デバイスを動的に削除せず、「使用不可」のマークをつけます。デバイスは、プロバイダーがシャットダウンされるまでメモリ内に残ります。結果として、EM 機能のログイン/ログアウトによって、メモリの使用量が増大し、システムに重大な影響を及ぼす可能性があります。過度に増加したメモリ使用を解放するためには Windows のテレフォニー サービスを再起動する必要があります。ただし、一般的には他のサービスとの依存関係から、テレフォニー サービス単体での再起動は難しいため、多くの場合、TAPI クライアントが動作する Windows マシンの再起動が必要となります。
EM のメモリ最適化オプション機能によって、同じ IP Phone 上にロードされた異なる EM プロファイル(デバイス プロファイル)で、同じ回線デバイス ID を再利用、共有することにより、LINE_CREATE/LINE_REMOVE に伴うメモリ使用量の消費を最小限に抑えます。異なる EM プロファイルで同じインデックス(回線位置)を持つ回線は、TAPI 回線デバイス ID が同じです。
この機能を有効または無効にするには、レジストリ設定を使用します。デフォルトでは、この機能は無効になるので、既存のアプリケーションは影響を受けません。
この機能が有効であると、EM プロファイルが特定の IP Phone に最初にロードされるときにのみ、Cisco Unified TSP によって LINE_CREATE メッセージが通知されます。一度作成された EM 回線は、LINE_REMOVE で削除されません。その代わり、EM ログアウトが発生すると、Inactive 状態に移行します。デバイスが Inactive 状態であると操作を実行できず、操作を実行しようとすると、LINEERR_DEVICE_INACTIVE エラーが返されます。
新規の EM ログインにより、EM プロファイルが IP Phone に再ロードされると、回線は再びアクティブになります。回線の再アクティブ化通知と一緒に、回線デバイスの機能が変更されたこともアプリケーションに通知されます。Other-Device 状態通知機能が、アクティブ メッセージ、非アクティブ メッセージ、および機能変更メッセージをアプリケーションに通知するために使用されます。詳細については、Other-Device 状態通知を参照してください。
(注) | EM のメモリ最適化オプション機能は、LINE_CREATE/LINE_REMOVE メッセージの使用を最小限に抑えるためのものです。機能が有効である場合でも、アプリケーションで LINE_CREATE メッセージおよび LINE_REMOVE メッセージを受信する場合もあります。したがって、既存の LINE_CREATE/LINE_REMOVE イベントと新規の LineActive/LineInactive 通知を処理できるように、アプリケーションを実装する必要があります。 |
この機能を有効または無効にするには、レジストリ設定を使用します。レジストリ設定は、Cisco TSP のインストールまたはアップグレード時に作成される EMOptions レジストリ エントリに保存されます。Cisco TSP レジストリ設定には 1 つの EMOptions エントリだけが存在し、ボックス内のすべての Cisco TSP インスタンスに適用されます。
EMOptions レジストリ設定は、手動で変更する必要があります。設定を変更するための Cisco TSP 設定インターフェイスは存在せず、機能の動作を動的に変更することはできません。変更した設定を有効にするには、Cisco TSP を再起動する必要(多くの場合、Windows の再起動が必要)があります。
対応するパラメータは、Cisco TSP のサイレント インストールにも使用できます。これにより、サイレント インストール時またはアップグレード プロセス時に、この機能を有効または無効にできます。
CiscoLineDevStateCloseReason は、LINEDEVSTATE_CLOSE 状態の詳細を示します。このパラメータは、LINE_LINEDEVSTATE メッセージの dwParam2 としてアプリケーションに通知されます。
enum CiscoLineDevStateCloseReason { CiscoLineDevStateCloseReason_Unknown = 0, CiscoLineDevStateCloseReason_LineNotAvailable, CiscoLineDevStateCloseReason_EMActivity };
エクステンション モビリティのメモリ最適化オプションを参照してください。
この機能を有効または無効にするには、レジストリ設定を使用します。デフォルトでは、この機能は無効になるので、既存のアプリケーションは影響を受けません。
外部コール制御は、Cisco Unified Communciations Manager で、企業ポリシーや個々のユーザのプレゼンスベースのルーティング ルールに基づいてコールをルーティングできるようにします。外部コール制御を有効にすると、Cisco Unified Communications Manager は企業ポリシーやユーザ ルールをホストする Web サービスに問い合わせを行い、返されたルーティング決定に基づいてコールをルーティングします。
TSP は、すべての Party 関連のフィールドにおいて変換前の電話番号やパーティションを受信するため、外部コール制御機能による影響を受けるシナリオはほとんどありません。TSP は、これらの変更されていないフィールドを TAPI の PartyId フィールドに渡します。外部コール制御機能は、変更された発信側と着信側の変更もできるため、TSP はこれを、lineCallInfo の devSpecific 部分の既存の変換後の電話番号フィールド(modified フィールド)に渡します。
外部コール制御機能の CTI でのサポートに伴い、トランスレーション パターンも本リリース以降サポートされます。トランスレーション パターンを経由するコールは、TSP によってサポートされます。またこのようなコールが会議に参加する場合、CONFERENCE コールの正しい番号が作成され、会議の間維持されます。
代行受信シナリオの lineCallInfo の devSpecific 部分の ExtendedCallReason フィールド内の新しい CtiReasonExternalCallControl(42)。
新しいデバイス固有エラーである LINEERR_OPERATION_FAIL_CHAPERONE_DEVICE は LINE_REPLY で、lineSetupConference/ lineAddToConference、lineDevSpecific(SLDST_START_CALL_RECORDING)および lineDrop 要求以外のシャペロン コールに関与するデバイスについての、拒否された要求に対して返されます。
CallAttributeBitMask フィールドの LINECALLINFO::DEVSPECIFIC は、新しいビット マスク TSPCallAttribute_ChaperoneCall を含むように変更されます。詳細については、詳細(Details)を参照してください。
外部コール制御を参照してください。
(注) | トランスレーション パターンを使用するコールの CallInfo に変更がありますが、このリリースよりも前のリリースで TSP はトランスレーション パターンをサポートしていなかったので、トランスレーション パターンのサポートは下位互換性があると考えられます。 |
連邦情報処理標準(FIPS)は公的に発表された標準で、米国連邦政府によって、すべての非軍事政府機関および政府関連企業によりコンピュータ システムで使用するために開発されました。FIPS 140-2 要件は、米国の NIST(国立標準技術研究所)とカナダの CSEC(カナダ通信安全保障局)が合同で定義されました。
Cisco Unified Communications Manager に FIPS コンプライアンス サポートを追加しました。このモードは、CallManager 管理コマンドライン インターフェイスで有効または無効にできます。
CiscoTSP 以降、CTI Manager または Cisco Unified Communications Manager との TLS 接続設定に使用する、FIPS 140-2 検証済み OpenSSL バージョンである "FIPS capable OpenSSL" ライブラリにアップグレードして、FIPS コンプライアンスをサポートします。Cisco TSP の FIPS モードは動的に更新できます。現在、CiscoTSP は FIPS Mode が有効で、Cisco Unified Communications Manager の FIPS Mode に依存します。
Cisco Unified TSP は、強制承認コード(FAC)とクライアント識別コード(CMC)という 2 つの Cisco Unified Communications Manager 機能をサポートしています。FAC 機能を使用すると、特定の着信番号に接続する前に、ユーザに対して承認コードの入力を求めることができます。CMC 機能を使用すると、特定の着信番号に接続する前に、ユーザに対してクライアント識別コードの入力を求めることができます。
システムは、電話機に "ZipZip" トーン(電話機が再生します)を送信して、FAC または CMC を入力する必要があることをユーザに通知します。アプリケーションが "ZipZip" トーンを再生する必要がある場合は、Cisco Unified TSP からアプリケーションに新しい LINE_DEVSPECIFIC イベントが送信されます。アプリケーションは、このイベントを使用して、FAC または CMC が必要であることを通知できます。アプリケーションで新しい LINE_DEVSPECIFIC イベントの受信を開始するには、次の手順に従う必要があります。
lineOpen 関数で、dwExtVersion を 0x00050000 以上に設定します。
lineDevSpecific - Set Status Messages でコール トーン変更のデバイス固有イベントをオンにします。
アプリケーションは、lineDial() API を使用して、FAC または CMC コードを入力できます。コード全体を一度に入力することも 1 桁ずつ入力することもできます。あるいは、アプリケーションでは、間を "#" 文字で区切り、末尾に "#" 文字を付ければ、同じ文字列に FAC と CMC の両方のコードを必要なだけ入力できます。ただし、末尾の "#" 文字は、ダイヤルの完了を示すのが目的なので、省略できます。
FAC または CMC を必要とする宛先に lineRedirect() または lineBlindTransfer() を実行すると、Cisco Unified TSP からエラーが返されます。Cisco Unified TSP から返されるエラーは、FAC、CMC、またはその両方が必要であることを示します。Cisco Unified TSP は、リダイレクトとブラインド転送をサポートする 2 つの新しい lineDevSpecific() 関数をサポートしています。これらの関数を使用すると、コールをリダイレクトまたはブラインド転送するときに、FAC、CMC、またはその両方をアプリケーションで入力できます。
Cisco Unified TSP に、lineForward() 要求のサポートが追加されました。この要求を使用すると、各回線の ForwardAll 情報の設定および消去を実行できます。これにより、特定の回線デバイスの不在転送設定を TAPI アプリケーションで設定することが可能になります。この機能を有効にすると、ユーザは無条件でコール転送を特定の転送先に設定できます。
lineForward() 要求が正常に完了すると、Cisco Unified TSP から LINE_ADDRESSSTATE メッセージが送信されます。これらのイベントは、Cisco Unified Communications Manager Administration やその他のアプリケーションなどのサードパーティから転送ステータスの変更を受信して、すべてのコールを転送に設定したことを示すコール転送指示を CTI から受信したときにも送信されます。
Cisco Unified Communications Manager はリリース 6.0 以降の録音ソリューションを提供しています。以前のリリースでは、通話録音は電話で対応していました。Cisco IP Phone を使用して、エージェントとお客様の 2 つのメディア ストリームをレコーダーにフォークまたは転送します。
ただし、関連デバイスが Unified Communications Manager に直接登録されていないコールのシナリオについては、電話による録音はできません。この状況では、モバイル エージェントによって処理されたコールは録音されません。また、モバイル コールの録音は、さまざまな管轄区域の規制により必要性が増していたり、コール センターや企業の重要なビジネス要件になったりしています。これらの要件により、エンドポイントからメディア フォークに依存しない録音ソリューションが求められています。
音声ゲートウェイに 2 つのメディア ストリームを音声レコーダーに転送させることで、録音ソリューションの強化は、シスコの音声ゲートウェイを通る外部コールを録音できます。このソリューションは、既存の CCiscoLineDevSpecificStartCallRecording API と CCiscoLineDevSpecificStopCallRecording API を使用して、ユーザが制御する録音セッションを開始および停止します。自動録音も回線に設定されています。音声ゲートウェイ、または特定の回線の優先録音リソースとして IP フォンを指定する追加オプションがあります。
さらに、Cisco Unified Communications Manager リリース 9.0 で導入された CTI リモート デバイスは、録音に有効なゲートウェイ経由での録音をサポートできるようになりました。CTI リモート デバイスとコールがルーティングされたリモート宛先の間に録音ゲートウェイがある場合、CTI リモート デバイスで録音を開始できます。発信者と CTI リモート デバイス間に録音ゲートウェイがある場合も、CTI リモート デバイスで録音を開始できます。CTI リモート デバイスで回線を設定し、自動または選択的録音をサポートすることもできます。CTI リモート デバイスはゲートウェイのみ使用してメディアをルーティングできます。
CTI ポートのコールは、Cisco Unified Communications Manager リリース 10.0(1) で利用可能なネットワーク録音機能を使用してをキャプチャできます。コール メディアは 1 つ以上の録音対応ゲートウェイを通過して録音する必要があります。一般的な使用例:CTI ポートのソフトフォンへの外部コール。CTI ポートの録音メディア ソースは常にゲートウェイ優先です。
ゲートウェイ録音をサポートするための設計変更により、以前のリリースでは見られなかった機能呼び出しにより、同じ録音を停止し、再開できます。以前は、この録音の停止と開始は、録音中のコールが保留にされ、再開された場合のみ確認されていました。このリリースでは、これは、録音中のコールの相手側が変わると発生する可能性があります。次に、例を示します。
操作 | 10.0 以前 | 10.0 |
---|---|---|
A が B をコールし、B が応答する | ||
TSP アプリケーションが A で CCiscoLineDevSpecificStartCallRecording を発行する。 | アプリケーションは A で SLDSMT_RECORDING_STARTED イベントを受信します | アプリケーションは A で SLDSMT_RECORDING_STARTED イベントを受信します |
B はコールを C に転送し、C が応答する | イベントは A で受信されません |
アプリケーションは A で SLDSMT_RECORDING_ENDED イベントを受け取ります アプリケーションは A で SLDSMT_RECORDING_STARTED イベントを受信します |
アプリケーションは、再度録音を開始する必要はありませんが、これらの追加イベントを処理する必要があります。
保留の復帰機能を使用すると、保留復帰期間のタイムアウト後に、保留している通話者に対して保留コールを通知できます。保留している通話者には、音声と視覚による保留復帰通知が発信されます。アプリケーションでは、Cisco TSP から保留復帰通知を受信するための保留復帰イベント フラグを設定できます。保留復帰イベントが発生してもコールの CallInfo と CallState は変わらず、アプリケーションで保留復帰イベント フラグを有効にしている場合には、保留復帰を示す LineCallDevSpecific イベントがアプリケーションに送信されます。
CiscoTSP は、ハント リストに含まれる回線とそのデバイスをサポートし、コールがハント パイロットによってオファーされていることをアプリケーションに認識させるための適切な情報を提供します。ハント リストに複数の回線グループを含め、各回線グループが異なるコール分配アルゴリズムを持つこともできます。回線グループで使用されるアルゴリズムに関係なく、CiscoTSP は一貫した情報をアプリケーションに提供します。
回線上でオファーされたコールがハント パイロットによってルーティングされる場合、CiscoTSP はハント パイロット ディレクトリ番号またはパーティションを、発信側、着信側、または接続 ID の LINECALLINFO::DEVSPECIFIC に格納します。ただし、リダイレクションおよびリダイレクト ID には、ハント パイロット情報が存在しません。ハント パイロット名は、LINECALLINFO::DEVSPECIFIC に渡されません。
ハント パイロット情報を報告する別個の LineDevSpecific イベントは存在しませんが、発信側、着信側、または接続 ID が変更された場合は、既存のイベントによって報告されます。
ハント リストはまた、コール ピックアップ機能と同時に使用することができます。ただし、コール ピックアップ機能を使用する場合は、ハント リストのブロードキャスト機能がサポートされません。この場合、ブロードキャストされたコールについて、ピックアップ通知は行われません。アプリケーションがハント リストのブロードキャスト コールをピックアップしようとすると、CTI または Cisco Unified Communications Manager がピックアップ要求に失敗します。
コールがハント リストにルーティングされ、回線グループのメンバによって着信が受け入れられた場合、着信情報がハント パイロットの情報となります。回線グループのメンバがコールに応答した後、ConnectedID に、実際の回線グループ メンバーの情報が設定され、LINECALLINFO::DEVSPECIFIC 内のフィールドにハント パイロット情報が設定されます。この場合、着信側 ID と接続 ID の両方に、ハント パイロット情報が含まれています。
会議の場合、接続された通話者のプライマリ コールがハント リストによってルーティングされているときは、ハント パイロットの電話番号またはパターンが提示されます。
(注) | この機能をサポートするには、アプリケーションが回線拡張バージョン 0x00A0000 以上でネゴシエートする必要があります。 |
ハント リストを参照してください。
Cisco Unified Communications Manager 9.0 では、発呼側でハント パイロットを使用するコールの着信側としてコールに応答したハント メンバを提供するようにハント パイロットのサポートが拡張されました。この拡張機能では、ユーザがハント パイロット HP を呼び出し、コールがハント リストの回線グループ メンバ LG1 によって応答された場合、TAPI は発信者の正規化情報構造の linecallinfo の devspecific 部分で ModifiedConnectedParty DN として HuntMember の DN を提供します。
この機能が無効な場合、提供される modifiedconnectedParty は HuntPilotDN です。
ハント パイロット情報は(HuntPilotInfo 構造体の)linecallinfo の devspecific 部分に使用できます。この機能が無効なときに提供された情報からこの機能を有効にすると、ハント パイロットを使用するコール シナリオのハント パイロット情報は変更されません。
ハント パイロット接続番号機能を参照してください。
この機能は下位互換性があります。これは、ハント パイロット ページの [回線グループ メンバ DN を接続側として表示(Display Line Group Member DN as Connected Party)] で有効にすることができます。デフォルトでは、この機能は無効になるので、既存のアプリケーションは影響を受けません。
この機能により、TSP アプリケーションは、制御するデバイスをハント グループにログイン/ログアウトさせることができます。さらに、TSP アプリケーションは、ハント グループのログイン ステータスについてデバイスにクエリできます。
TSP アプリケーションがハント グループに正常にログインまたはログアウトした後、TSP アプリケーションは電話イベントを送信して、関連するアプリケーションに更新されたログイン ステータスを通知します。ステータスを変更する要求によって実際にはステータスの変更が発生しない場合(たとえば、TSP がデバイスをハント グループにログインさせようとしたが、そのデバイスがすでにそのグループにログインしている場合など)、通知は送信されません。
この機能をサポートするため、2 つのインターフェイスが更新されました。
ハント グループにログイン/ログアウトするために、CCiscoPhoneDevSpecificSetHuntGroupLoginStatus 拡張機能が既存の CCiscoPhoneDevSpecific インターフェイスに追加されました。新しい拡張機能には、mHuntGroupLoginStatus という列挙型があります。
ハント グループのログイン ステータスをクエリするために、既存の LineGetDevCapsinterface に新しい拡張機能 Cisco_LineDevCaps_Ext000E0000 が追加されました。新しい拡張機能には、DeviceHuntGroupLoginStatus というメンバー変数があります。
(注) | ハント グループにログインおよびログアウトするには、アプリケーションが行拡張子 0x000E0000 以上をネゴシエートする必要があります。この機能の一部として、新しい行拡張子が追加されました。 この機能を利用するには、アプリケーションは最小拡張バージョンが 0x00030000 の TAPI 電話デバイスを開く必要があります。 |
ハント グループ ログインは、次のデバイス タイプではサポートされていません。ログイン要求は LINEERR_OPERATIONUNAVAIL エラーを返します。
ハント グループ ログイン ステータスの列挙型の値の範囲は、0 ~ 2 の範囲内でなければなりません。それ以外の場合、要求は LINEERR_INVALPARAM を返します。
ハント グループ ログイン ステータスを設定する要求が処理中で、2 つ目の要求が送信された場合、2 つ目の要求は LINEERR_PENDING_REQUEST エラーを返します。
none
インターコム機能を使用すると、特定のユーザから別のユーザにコールを発信し、着信側がビジー状態またはアイドル状態であったとしても自動的にコールに応答して、発信側から着信側への一方向メディアを確立できます。
誤って着信側の声を発信側に返すことのないよう、Cisco Unified Communications Manager は「ウィスパー」インターコムを実装します。「ウィスパー」インターコムを使用すると、発呼側からの片通話だけが接続され、着信側からの音声は接続されません。着信側から発信側に音声を返すには、手動でキーを押す必要があります。発信側の声が着信側に聞こえる前に、「zip-zip」(自動応答)トーンが再生されます。現在のインターコム コールで音声が一方向だけに送信されているか双方向に送信されているかは、両方のインターコム ボタンによって示されます。片通話のウィスパー インターコムである場合は、このボタンがオレンジ色で点灯し、音声が双方向に送信されている場合は緑色で点灯します。TSP アプリケーションから見ると、一方向のウィスパー インターコムの場合、発信側または着信側で発生する RTP イベントは 1 つだけであり、コール状態はウィスパー インターコムであると認識されます。
TSP は、LineDevCap の DevSpecific 部分を使用してインターコム回線表示とインターコム短縮ダイヤル情報を提供します。アプリケーションは、LineGetDevCaps を発行することでこれらの情報を取得できます。TSP は DevSpecific 部分を使用して、この回線がインターコム回線であるかどうかを示す情報(DevSpecificFlag = LINEDEVCAPSDEVSPECIFIC_INTERCOMDN)を提供します。インターコム短縮ダイヤル情報は、パーティション フィールドの後にある DevSpecific 部分から取得できます。
インターコムで CTI ポートを使用する場合、アプリケーションは動的メディア終端を使用して CTI ポートをオープンする必要があります。静的メディア終端を使用してインターコム回線がオープンされた場合、TSP は LINEERR_OPERATIONUNAVAIL を返します。
(注) | インターコム機能では CTI ルート ポイントを使用できません。 |
管理者は、Cisco Unified Communications Manager の管理で、スピード ダイヤル オプションとラベル オプションを設定できます。アプリケーションからインターコム回線のスピード ダイヤルとラベルの設定またはリセットを実行するには、SLDST_LINE_SET_INTERCOM_SPEEDDIAL を含む CCiscoLineSetIntercomSpeeddial を発行します。管理者によって設定されたデータベース内の値は、アプリケーションによって設定された値で上書きされます。Cisco Unified Communications Manager は、回線がクローズされるか、アプリケーションによってリセットされるまで、アプリケーションによる設定でインターコム コールを発信します。Communications Manager または CTIManager のフェールオーバーが発生した場合は、CTIManager または Cisco TSP によってアプリケーションの短縮ダイヤル設定がリセットされます。アプリケーションを再起動する場合は、アプリケーション側でスピード ダイヤル設定をリセットします。リセットしなければ、Cisco Unified Communications Manager は、データベースの設定でインターコム コールを発信します。いずれの場合も、スピード ダイヤルおよびラベルのリセットに失敗した場合は、失敗を通知する LINE_DEVSPECIFIC イベントが送信されます。アプリケーションによる設定を解除して短縮ダイヤル設定をデータベースの設定に戻すには、SpeedDial および Label の値を NULL に設定して CciscoLineSetIntercomSpeeddial を呼び出します。
データベース内で値が変更されたか、アプリケーションによって設定が上書きされたかに関係なく、短縮ダイヤル設定が変更された場合は、その変更を通知するために LineDevSpecific イベントが生成されます。ただし、この通知をアプリケーションで受信するには、DEVSPECIFIC_SPEEDDIAL_CHANGED を含む CCiscoLineDevSpecificSetStatusMsgs を呼び出す必要があります。この通知を受信した後に LineGetDevCaps を呼び出すと、現在のスピード ダイヤル設定とラベル設定を検出できます。
ユーザはインターコム コールを開始するには、発信者側の電話機でインターコム ボタンを押すか、(インターコム回線でスピード ダイヤルとラベルが設定されている場合は)宛先を NULL に設定して LineMakeCall を発行します。設定されていない場合は、LineMakeCall で正しいインターコム DN を指定する必要があります。
インターコム コールの場合、LINECALLINFODEVSPECIFIC の CallAttribute フィールドは、そのコールがインターコム発信者とインターコム受信者のどちらに対するものであるかを示します。
インターコム コールが確立されると、トーン変更イベントとして、アプリケーションに「zip-zip」トーン イベントが送信されます。
着信側のユーザは、次の 2 つの方法で応答(TalkBack)を開始できます。
コール状態が Whisper の場合は、拡張コール状態ビットが CLDSMT_CALL_WHISPER_STATE に設定されます。着信者が TalkBack を使用してインターコムに応答しているためにコールが保留されている場合、保留されているコールの拡張コール理由フィールドは CtiReasonTalkBack に設定されます。
インターコム コールの開始、終了、応答(TalkBack)を除き、アプリケーション側から回線機能を設定できません(たとえば、コール転送の設定や、メッセージ受信ランプの設定はできません)。インターコム コールが確立されると、そのコールに対して実行できるコール機能は制限されます。発信側から実行できる機能は LINECALLFEATURE_DROP だけになります。着信側から実行できる機能は、LINECALLFEATURE_DROP 機能とウィスパー インターコム コールに対する応答(TalkBack)機能だけになります。着信側が応答(TalkBack)を開始してインターコム コールが双方向音声になった場合、着信側から実行できる機能は LINECALLFEATURE_DROP だけになります。
IPv6 のサポート機能により、Cisco Unified Communications Manager ネットワークで IPv6 機能を使用できます。IPv6 では、ネットワーク デバイスで使用できるアドレスの数が増加しています。Unified CM で IPv6 のサポート機能が有効になっている場合、TAPI は IPv6 のサポートにより Unified CM に接続することができます。IPv6 の拡張機能には次のようなものがあります。
発信側の IPv6 アドレスを LINECALLINFO の Devspecific 部分に格納し、着信側に提供する。
CTI ポートやルート ポイントに IPv6 アドレスを登録する。このデバイスでメディアが確立された場合は、RTP の宛先に IPv6 アドレスが含まれます。
TSP の設定画面では、プライマリおよびバックアップ CTI Manager アドレスと、CTI Manager への接続時に使用するアドレス モードの優先順位を設定できます。CTI ポートとルート ポイントには IPv4 と IPv6 のいずれか一方または両方を登録できます。
次の新しい CiscoLineDevSpecific 関数を使用すると、CTI ポートとルート ポイントを開く前にアプリケーションで IP アドレス モードと IPv6 アドレスを指定できます。
ダイナミック ポート登録では、アプリケーションは SLDSMT_OPEN_LOGICAL_CHANNEL イベントの受信時に CCiscoLineDevSpecificSetRTPParamsForCallIPv6 によりコールの IPv6 情報を提供します。
IPv6 アドレスとモードの設定を参照してください。
IPv6 の使用例を参照してください。
Cisco Unified Communications Manager で、[Join(参加)] ソフトキーは、確立済みコール(2 つ以上)の通話者を 1 つの電話会議に参加させることができます。「参加」機能では、コンサルト コールが開始されず、アクティブ コールが保留状態に変更されることはありません。3 つ以上のコールを含めることもできるので、1 つのコールに 4 人以上を参加させることも可能です。
lineDevSpecific() - Join という新しいデバイス固有関数を使用することで、Cisco Unified TSP から参加機能を利用できます。この関数は、2 つ以上の確立済みコールに対して実行できます。lineSetupConference() 関数または linePrepareAddToConference() 関数を使用して、これらの 2 つのコールを最初に確立する必要はありません。
Cisco Unified TSP では、lineCompleteTransfer() 関数で dwTransferMode=Conference を指定することもできます。TAPI アプリケーションでこの関数を使用すると、2 つの確立済みコールの通話者全員を 1 つの電話会議に参加させることができます(サポートされる確立済みコールの数は 2 つだけです)。
また、Cisco Unified TSP では、lineAddToConference() 関数で、ONHOLD 状態の既存の電話会議にコールを追加することもできます。
参加、共用回線、およびコール最大数に関しては、機能の相互干渉の問題があります。この問題は、共用回線が 2 本あり、一方の回線のコール最大数が他方の回線のコール最大数よりも少ない場合に発生します。
たとえば、共有回線 A のコール最大数が 5 に設定されており、共有回線 A’ のコール最大数が 2 に設定されていると仮定します。この状況で、次のような手順が実行されたとします。
A が B を呼び出し、B が応答する。A が、コールを保留にする。
C が A を呼び出し、A が回答する。C が、コールを保留にする。
この時点で、回線 A には ONHOLD 状態のコールが 2 つあり、回線 A’ には CONNECTED_INACTIVE 状態のコールが 2 つあります。
この時点で、このコールは A には提示されますが、A’ には提示されません。これは、A’ のコール最大数が 2 に指定されているからです。
A が電話機または lineDevSpecific – Join API を使用して参加操作を実行し、すべての通話者を会議に参加させる。A と D の間のコールが、参加操作のプライマリ コールとして使用される。
A と D の間のコールが参加操作のプライマリ コールとして使用されたため、確立された電話会議は A’ に対して存在していないことになります。A’ 上のコールは両方とも IDLE 状態に移行します。その結果、A に提示されている電話会議が A’ には提示されていないという状態が発生します。
この機能では、参加操作を使用して、同じデバイスの異なる回線に複数のコールが参加できるようになります。アプリケーションは既存の join API を使用してタスクを実行できます。複数ライン同時通話機能が使用されると、持続するコールがない別の回線上のコンサルト コールがクリアされ、コンサルト コールを表す CONFERENCED コールが、親の会議を開催するプライマリ回線に作成されます。同じ回線上で複数のコールに参加している場合でも、この機能による影響はありません。
この機能は、CTI で制御できる SCCP デバイスでサポートされます。また、この機能によって、同じデバイス上の別の回線での電話会議のチェーニングもサポートされます。さらに、複数ライン同時通話機能は、コントローラ以外の回線(元の会議コントローラが、参加を実行するデバイスと異なるデバイスにある)でも実行できます。
(注) | 複数ライン同時通話機能に関与している回線にインターコム回線がある場合は、この機能によってエラーが返されます。 |
この機能では、同じデバイスの異なる回線に複数のコールが参加操作で参加できます。アプリケーションは既存の join API を使用してタスクを実行できます。複数ライン同時通話機能が使用されると、持続するコールがない別の回線上のコンサルト コールがクリアされ、コンサルト コールを表す CONFERENCED コールが、親の会議を開催するプライマリ回線に作成されます。同じ回線上で複数のコールに参加している場合でも、この機能による影響はありません。
この機能は、CTI で制御できる SCCP と SIP の両方のデバイスでサポートされます。また、この機能によって、同じデバイス上の別の回線での電話会議のチェーニングもサポートされます。さらに、複数ライン同時通話機能は、コントローラ以外の回線(元の会議コントローラが、参加を実行するデバイスと異なるデバイスにある)でも実行できます。
複数ライン同時通話機能に関与している回線にインターコム回線がある場合は、この機能によってエラーが返されます。
回線をまたいで参加を参照してください。
TSP では、SIP を実行する TNP ベースの電話機の制御およびモニタリングがサポートされています。SIP を使用している既存の電話機(7960 および 7940)は、TSP から制御やモニタができず、制御リストに含めることができません。SIP を実行する電話機は通常、SCCP を実行する電話機と同様の動作をしますが、TSP のすべての機能が SIP を実行する電話機でサポートされているわけではありません。
UDP で設定されている SIP を実行する電話機では、UDP の制限があるため、CCiscoPhoneDevSpecificDataPassThrough 機能がサポートされていません。CCiscoPhoneDevSpecificDataPassThrough 機能が必要な場合は、SIP を実行する電話機で TCP を使用する(デフォルト)ように設定されている必要があります。
UDP を使用する SIP を実行する TNP 電話機についての TSP のアプリケーション登録状態は、電話機の登録状態とは一致していない可能性があります。アプリケーションによってデバイスがアウト オブ サービスであることを報告する際には、UDP を使用する SIP を実行する TNP 電話機が登録されていると見なされることもあります。この状況は、CTIManager が Unified CM がダウンしていると判断し、デバイスをアウト オブ サービスにするときに起こる可能性があります。UDP では接続切れが検出されるまでに時間差が生じ、電話機がサービス中であるように見えるためです。
アプリケーションが SIP を実行する電話機でデバイスおよび回線をオープンする方法は、SCCP を実行する電話機と同じです。リオーダー音を再生するタイミングと長さを制御するのは SIP を実行する電話機です。SIP を実行する電話機がリオーダー音の再生要求を受け取ると、その電話機は Unified CM からリソースを解放し、リオーダー音を再生します。リオーダー音が電話機でこれから再生されるにもかかわらず、TSP アプリケーションにはそのコールが IDLE 状態に見えます。電話機によってリオーダー トーンが再生される場合でも、アプリケーションはその電話機からのコールを受信して開始することができます。Unified CM 上にリソースが解放されているため、このコールはビジー トリガーおよびコール カウンタの最大数をカウントしません。
SIP でコンサルト コールが起動されると、(コンサルト コールの)新規のコール イベントおよび保留中コールの状態の順序によって、(元のコールの)イベントが変更されます。
リリース 7.0(1) から、TSP のローカリゼーションが自動化されました。TSP の UI では、新規および更新されたロケール ファイルを、設定された TFTP サーバ ロケーションから直接ダウンロードできます。ダウンロード機能を使用すると、Cisco TSP のインストール中には英語だけがサポートされます。
インストール時に、ユーザは TFTP サーバの IP アドレスを入力します。ユーザが TSP インターフェイスを初めてオープンするとき、TSP インターフェイスは、設定された TFTP サーバから自動的にロケール ファイルをダウンロードし、それらのファイルをリソース ディレクトリに抽出します。TSP 設定の UI の言語タブでも、ロケール ファイルの更新が可能です。
(注) | Cisco Unified Communications Manager Release 6.0(1) TSP から Cisco Unified Communications Manager Release 7.0(1) TSP にアップグレードする場合、リリース 6.0(1) TSP は、英語でインストールされていなければなりません。リリース 6.0(1) TSP が英語以外のいずれかの言語でインストールされている場合にリリース 7.0(1) TSP にアップグレードするには、コントロール パネルの [追加/削除(Add/Remove)] プログラムから手動で 6.0(1) TSP をアンインストールし、リリース 7.0(1) TSP をはじめからインストールする必要があります。 |
Cisco TSP インストーラには、英語ロケールだけがパッケージされています。TSP UI によって、設定された TFTP サーバからロケール ファイルがダウンロードされます。エンド ユーザは、必要なサポートされているロケールを、インストール後に選択できます。
論理パーティション機能は VoIP から PSTN へのコールや PSTN から VoIP へのコールを、論理パーティション ポリシーに基づいて制限します。地理的に異なる 2 か所の場所の間で VoIP コールと PSTN コールをつなぐ要求はすべて失敗し、エラー コードがアプリケーションに返されます。
デバイス、デバイス プール、トランク、ゲートウェイ ページでは geo-location 値を選択するための設定と、geo-location 文字列の作成ルールを使用できます。
この機能のため、新しいエンタープライズ パラメータが追加されています。値は次のとおりです。
この機能のために、エラー コード、LINEERR_INVALID_CALL_PARTITIONING_POLICY 0xC000000C、を追加しました
論理パーティション設定を参照してください。
この機能は下位互換性があります。以前の動作を維持するには、Logical partitioning enabled パラメータを False に設定します。
メッセージ受信インジケータ(MWI)の改良により、アプリケーションはサポートしている電話機に次の情報を表示できるようになりました。
新しい音声メッセージ(標準の優先度と高い優先度)の合計件数
以前の音声メッセージ(標準および高い優先度を含む)の合計件数
高い優先度の新しい音声メッセージの件数
高い優先度の以前の音声メッセージの件数
新しい FAX メッセージ(標準の優先度と高い優先度)の合計件数
以前の FAX メッセージ(標準の優先度と高い優先度)の合計件数
高い優先度の新しい FAX メッセージの件数
高い優先度の以前の FAX メッセージの件数
また、MWI には 2 つの CCiscoLineDevSpecific サブクラスが追加され、MWI 機能が改良されています。1 つめのサブクラスは、既存の SetMessageWaiting と同様に、特定の制御回線に対してメッセージ概要を設定します。もう 1 つのサブクラスは、制御回線に設定されたコーリング サーチ スペースを基に到達可能な任意の回線に対してメッセージ概要を設定します。
メッセージの概要 およびメッセージ要約電話番号 を参照してください。
Microsoft Windows Vista オペレーティング システムで Cisco TSP クライアントを使用するためには、以下のような設定が必要になります。
Cisco TSP と Cisco Unified Communications Manager TSP Wave Driver の初期インストールを必ず新規インストールとして実行します。
Cisco Unified Communications Manager へのセキュア接続を使用する場合、Windows ファイアウォールをオフまたは無効にします。
Cisco Unified Communications Manager TSP Wave Driver を着信オーディオ ストリーミングに使用する場合は、Windows ファイアウォールをオフか無効にしてください。
Cisco Unified Communications Manager TSP Wave Driver をオーディオ ストリーミングに使用する場合は、[サウンド、ビデオ、およびゲーム コントローラ(Sound, video and game controllers)] グループの他のデバイスをすべて無効にしてください。
Cisco Unified TSP は、Cisco Unified CM の管理のコール パーク ディレクトリ番号(Call Park DN)で表現される回線上でのコール モニタリングをサポートしています。Cisco TSP は、LINEDEVCAPS 構造体のデバイス固有拡張を使用して、TAPI アプリケーションによるコール パーク DN 回線と他の回線との区別を可能にしています。アプリケーションがコール パーク DN 回線をオープンした場合は、そのコール パーク DN で保留されているすべてのコールがアプリケーションにレポートされます。アプリケーションは、コール パーク DN で保留されているコールに対して、コール制御機能を実行できません。
コール パーク DN 回線をオープンするには、Cisco Unified Communications Manager Administration で、その TSP ユーザに対して [コール パーク DN のモニタ(Monitor Call Park DN)] チェックボックスをオンにする必要があります。それ以外の場合、初期化中に、アプリケーションがコール パーク DN 回線を認識できなくなります。
ライン アピアランス 1 つあたりのコール数の上限は、データベースで設定できます。これは、Cisco TSP が Multiple Call Display(MCD)デバイスにおいて 1 回線あたり 3 つ以上のコールをサポートすることを意味します。MCD デバイスとは、DN あたり 3 つ以上のコール インスタンスを常に表示できるデバイスです。MCD 以外のデバイスの場合、Cisco TSP でサポートされる 1 回線あたりのコール数は 2 つまでです。ライン アピアランス 1 つあたりのコール数の絶対的上限は 200 です。
Cisco Unified CM にはビジー トリガーという設定があり、このビジー トリガー設定によってライン アピアランスごとのコール数の制限が指定されます。この制限を超えた場合、着信コールは Cisco Unified CM に拒否されます。ビジー トリガー設定は、ライン アピアランスごと、またはクラスタごとにデータベースで指定できます。DN ごとの古いコール待機フラグは、ビジー トリガーの設定で置き換えられます。Cisco TSP を使用してビジー トリガー設定を変更できません。
無応答時コール転送タイマーは、DN およびクラスタごとにデータベースで設定できます。Cisco TSP を使用してこのタイマーを設定できません。
Cisco TSP では、アプリケーションが新しい Cisco Media Driver(次世代の Wave ドライバ)を使用することができるようになりました。Cisco Media Driver を使用すると、従来のカーネル モードのドライバに近い機能を利用できる上、アプリケーションのスケーラビリティが向上し、最新リリースの Microsoft オペレーティング システムがサポートされます。
新しいドライバをサポートするため、ciscowave/in と ciscowave/out の 2 つの追加のデバイス クラスが導入されています。新しい Cisco Media Driver を音声ストリーミングに使用する際は、これらの新しいクラスを lineGetID() に指定して、回線に関連付けられたメディア デバイスの回線デバイス ID を取得できます。詳細については、Cisco TSP Media Driverを参照してください。
標準的な TAPI の仕様には、非オープン デバイスの状態変更を通知する機能はありません。この通知機能は、Other-Device 状態通知機能によって Cisco TSP に導入されます。アプリケーションはこの Other-Device 機能を使用して、非オープン デバイスの状態変更をアプリケーションに通知するために Cisco TSP が使用するデバイスを割り当てることができます。
現在、Cisco TSP は回線デバイスに対してのみこの機能をサポートしています。アプリケーションは、CCiscoLineDevSpecificSetStatusMsgs lineDevSpecific 要求に DEVSPECIFIC_OTHER_DEVICE_STATE_NOTIFY フラグを使用して、オープン済みの回線デバイスでこの機能を有効にすることができます。次に、Cisco TSP がこの回線を使用して、Other-Device の状態変更通知をアプリケーションに送信します。通知は、次のように LINE_LINEDEVSTATE メッセージで送信されます。
LINE_LINEDEVSTATE hDevice = (DWORD) hLine; dwCallbackInstance = (DWORD) hCallback; dwParam1 = (DWORD) LINEDEVSTATE_OTHER; dwParam2 = (DWORD) CISCO_LINEDEVSTATE_OTHER_REASON_constant; dwParam3 = (DWORD) dwLineDeviceId;
CiscoLineDevStateOtherReason 列挙型では、この通知の Param2 のすべての関連値を定義します。Param3 には、状態が変化した回線デバイスの TAPI の lineDeviceId を設定します。
Other-Device 状態通知は、非オープン デバイスの状態変更通知をアプリケーションに提供するその他の機能が使用する補足的なメカニズムです。たとえば、EM のメモリ最適化では、EM のログインまたはログアウトの結果として回線デバイスがアクティブまたは非アクティブになった場合に、この機能でアプリケーションに通知します。
CiscoLineDevStateOtherReason 列挙型は、LINEDEVSTATE_OTHER の詳細を示し、LINE_LINEDEVSTATE メッセージの dwParam2 としてアプリケーションに渡されます。
enum CiscoLineDevStateOtherReason { CiscoLineDevStateOtherReason_Unknown = 0, CiscoLineDevStateOtherReason_OtherLineInactive, CiscoLineDevStateOtherReason_OtherLineActive, CiscoLineDevStateOtherReason_OtherLineCapsChange };
lineDevSpecific 要求のステータス メッセージの設定で DEVSPECIFIC_OTHER_DEVICE_STATE_NOTIFY フラグを使用して Other-Device ステート通知を有効にします。詳細については、ステータス メッセージの設定を参照してください。
エクステンション モビリティのメモリ最適化オプションを参照してください。
Other-Device 状態通知は補足的な機能であり、非オープン デバイスの状態変更通知をアプリケーションに提供することを必要とするその他の機能で使用するためのものです。特定の機能に関しては、下位互換性を考慮する必要があります。詳細については、エクステンション モビリティのメモリ最適化オプションを参照してください。
パーク モニタリング機能を使用すると、パーク中のコールのステータスをモニタできます。この機能により、パーク中のコールの取得に対するユーザ エクスペリエンスが向上します。TAPI がパーク中のコールの通知を受け取ると、パーク中のコールを表すコールが生成され、CONNECTED INACTIVE 状態に設定されます。パーク中のコールは、取得または [未取得時のパーク モニタリング転送の接続先(Park Monitoring Forward No Retrieve Destination)] の転送先に転送された場合に IDLE に設定されます。
コールのパーク、アラーム、取得、または中止が実行されると、DEVSPECIFIC_PARK_STATUS イベントが送信されます。LineDevSpecific SLDST_SET_STATUS_MESSAGES が改良され、アプリケーションが DEVSPECIFIC_PARK_STATUS イベントを有効または無効にできるようになりました。
Cisco TSP が新しくパークされたコールの LINE_PARK_STATUS イベントを受信すると、Cisco TSP は LINE_PARK_STATUS イベントから取得した SubID を使用して、新しくパークされた各コールのシミュレーションを実行します。その後、LINE_NEWCALL イベントを使用して、新しくパークされたコールについてアプリケーションに通知します。
Cisco TSP は LINE_CALLSTATE イベントを使用してパークのステータスの変更をアプリケーションに通知します。LINE_CALLSTATE イベントのパークのステータスは次のいずれかです。
Parked:TSP がモニタリングしている Cisco Unified IP Phone がコールをパークしていることを示します。
Retrieved:以前にパークされたコールを取得したことを示します。
Abandoned:以前にパークされたコールが、取得待機中に接続切断されたことを示します。
Reminder:パーク中のコールのパーク モニタリング復帰タイマーの設定時間が過ぎたことを示します。
Forwarded:パーク中のコールが、設定された [未取得時のパークモニタリング転送の接続先(Park Monitoring Forward No Retrieve Destination)] に転送されたことを示します。FNR 接続先を設定していなければ、コールはパーク元に返されます。
Cisco TSP が LINE_PARK_STATUS イベントを受信すると、既存の CALLINFO 構造体に LINE_PARK_STATUS イベントから取得したフィールドがマップされます。アプリケーションは lineGetCallInfo を呼び出して、更新された構造体を取得します。
LINECALLINFO 構造体への LINE_PARK_STATUS イベントのフィールドのマッピングは次のとおりです。
parked、retrieved、abandoned、reminder、forwarded:パーク中コールのステータスを表す |
||
SIP を実行している Cisco Unfied IP Phone のパーク機能の既存の動作を維持するには、[パーク モニタリング復帰タイマー(Park Monitoring Reversion Timer)] の値を既存の [Call Park Reversion] タイマーと同じに設定し、[未取得時のパークモニタリング転送の接続先(Park Monitoring Forward No Retrieve Destination)] を空白にします。
SIP を実行している Cisco Unfied IP Phone のパーク モニタリング機能を無効にするには、lineDevSpecific SLDST_SET_STATUS_MESSAGES 要求を使用して DEVSPECIFIC_PARK_STATUS メッセージ フラグを停止します。
ステータス メッセージの設定を参照してください。
パーク モニタリングを参照してください。
この機能により Cisco TSP でパーティション情報がサポートされます。リリース 5.1 よりも前のリリースでは、CiscoTSP でアプリケーションに報告されるのは DN についての部分的な情報だけで、割り当てられた番号は含まれていましたが、関連付けられているパーティションについての情報はありませんでした。
このため、1 台の電話に 2 つの回線が同一の DN を使用して設定されていて、一方がパーティション P1 でもう一方が P2 の場合、TSP アプリケーションはこれら 2 つが区別できず、結局、2 つのうち 一方の回線だけしか開けませんでした。
CiscoTSP はすべての DN に関するパーティション情報をアプリケーションに提供します。これにより、上記の制限事項はなくなり、同じ DN を共有しながら異なるパーティションに所属する同じデバイス上の 2 つの回線がアプリケーションから区別でき、両方の回線を開けます。
TSP アプリケーションは、LINEDEVCAPS 構造体の DevSpecific 部分からパーティション情報が取得可能です。アプリケーションは、コールの CallerID、CalledID、ConnectedID、RedirectionID、および RedirectingID のパーティション情報を取得します。これは、LINECALLINFO 構造体の DevSpecific の部分として提供されます。
また、コールがパークされたコール パーク DN のパーティション情報も、アプリケーションに送信されます。パーティション情報の値は、アプリケーションに ASCII フォーマットで送信されます。
(注) |
パスワードの有効期限切れの通知で、パスワードが期限切れになる日付をユーザに通知し、パスワードがすでに期限切れになっている場合やアカウントがロックされている場合の初期化失敗の特定の理由を提供します。ユーザは、クレデンシャル ポリシーを作成してユーザ パスワードのクレデンシャルと同じクレデンシャルを関連付けることができます。
CiscoTSP アプリケーションの起動後に、パスワードの有効期限切れの通知が表示されます。この情報は、アプリケーションが最初に読み込まれるときに 1 回だけ表示され、定期的には更新されません。
アプリケーションがすでに起動されていて、2 つ目のアプリケーションを開始すると、アプリケーションがすでに読み込まれているため、パスワードの有効期限切れの通知は再び表示されません。
CiscoTSP はユーザに、次のようにパスワードの有効期限切れについて通知します。
CiscoTSP Notifier からのポップアップ メッセージ:「Unified CM TSP 初期化成功 - パスワードの期限切れまでの日数: 9(Unified CM TSP initialization Success - Password will Expire in Days : 9)」
アプリケーション イベント ログ メッセージ:「情報 : パスワードの有効期限が [9] 日以内に切れます。(Information : Password will Expire in [9] Days)」
パスワードが有効期限切れの場合、CiscoTSP 初期化が失敗し、メッセージが表示されます。
クレデンシャル ポリシーで設定したユーザのパスワードは、次のいずれかの理由で期限切れになります。
期限切れパスワードは管理者またはユーザのいずれかがリセットできます。
CiscoTSP はユーザに、次のように有効期限切れになったパスワードについて通知します。
CiscoTSP Notifier からのポップアップ メッセージ:「Unified CM TSP 初期化失敗 - パスワードの有効期限が切れています。パスワードをリセットしてください。(Unified CM TSP initialization failed - Password has Expired, Please RESET Password)」
アプリケーション イベント ログ メッセージ:「エラー : パスワードの有効期限が切れているため、プロバイダーのオープンが失敗しました。ユーザはパスワードをリセットできます。(ERROR : Provider Open Failed as Password is expired. User can RESET the Password)」
CiscoTSP Notifier からのポップアップ メッセージ:「Unified CM TSP 初期化失敗 - パスワードの有効期限が切れています。ユーザはパスワードをリセットできません。管理者にお問い合わせください。(Unified CM TSP initialization failed - Password has Expired, User cannot RESET the Password, Please contact ADMIN)」
アプリケーション イベント ログ メッセージ:「エラー : パスワードの有効期限が切れているため、プロバイダーのオープンが失敗しました。ユーザはパスワードをリセットできません。管理者にお問い合わせください。(ERROR : Provider Open Failed as Password is expired.)」
正しくないログインのしきい値の回数を超えた場合。これは、ユーザ クレデンシャル ページの [失敗ログイン(Failed Logon)] に表示されます。
管理者がユーザ アカウントをロックした場合。
ユーザ クレデンシャル ページで指定した日数の間、クレデンシャルが使用されておらず、非アクティブを理由にアカウントがロックされた場合。これは、ユーザ クレデンシャル ページの [許可される非アクティブ日数(Inactive Days Allowed)] に表示されます。
CiscoTSP はユーザに、次のように初期化失敗について通知します。
CiscoTSP Notifier からのポップアップ メッセージ:「Unified CM TSP 初期化失敗 - アカウントがロックされています(Unified CM TSP initialization failed - Account is LOCKED)」。
アプリケーション イベント ログ メッセージ:「エラー: ユーザ アカウントがロックされているため、プロバイダーのオープンが失敗しました。(ERROR: Provider Open Failed as User Account is LOCKED)」
Cisco Unified Communications Manager のプライバシー リリース機能を使用すれば、ユーザはプライバシー設定を動的に変更できます。プライバシー設定は、デバイス上の既存および将来のコールすべてに影響します。Cisco Unified TSP は、プライバシー リリース機能をサポートしていません。
この機能により、Cisco TSP アプリケーションは LineDevSpecific API を使用して、特定のデバイスにコールをリダイレクトできます。デバイスが電話回線を共有している場合でも、ターゲット デバイスだけが鳴り、電話回線を共有しているデバイスは鳴りません。この機能は、Cisco Emergency Responder の PSAP コールバック機能によって使用されます。
この機能をサポートするために、新しい CCiscoLineDevSpecific 拡張機能「CciscoLineDevSpecificRedirectEx」が追加されました。この拡張機能には、ターゲット デバイスを指定する新しい RedirectDeviceName フィールドがあります。この拡張機能には、次のようなリダイレクト機能のバリエーションがあります。
リダイレクト先に到達できない場合、LINEERR_INVALADDRESS が返されます。
Cisco Unified TSP は、数種類のリダイレクト方式とブラインド転送方式をサポートしています。このセクションでは、さまざまな方式および各方式の相違の概要を説明します。
TAPI 標準の lineRedirect 関数は、指定された宛先にコールをリダイレクトします。この関数用に Cisco Unified TSP で使用されるコーリング サーチ スペースと元の着信者は次のとおりです。
この関数は、元の着信者を、コールをリダイレクトしている通話者にリセットして、指定された宛先にコールをリダイレクトします。この関数用に Cisco Unified TSP で使用されるコーリング サーチ スペースと元の着信者は次のとおりです。
この関数は、元の着信者を、アプリケーションが任意の値に設定できるようにして、指定された宛先にコールをリダイレクトします。この関数用に Cisco Unified TSP で使用されるコーリング サーチ スペースと元の着信者は次のとおりです。
コーリング サーチ スペース(CSS):CallingParty(リダイレクトされている通話者)の CSS が使用されます。
元の着信者:lineDevSpecific 関数で指定された preferredOriginalCalledID に設定されます。
この要求を使用すると、Transfer to Voice Mail(TxToVM)機能を実装できます。この機能を使用すると、別の回線上のボイスメールボックスにコールを直接転送できます。TxToVM を実行するには、上記の要求のフィールドで、宛先 DN としてボイスメール パイロットを指定し、preferredOriginalCalledID としてコールの転送先となるボイスメールボックスの回線 DN を指定します。
この関数は、FAC または CMC のどちらかまたは両方が必要な指定された宛先に、コールをリダイレクトします。この関数用に Cisco Unified TSP で使用されるコーリング サーチ スペースと元の着信者は次のとおりです。
TAPI 標準の lineBlindTransfer 関数は、指定された宛先にコールをブラインド転送します。この関数用に Cisco Unified TSP で使用されるコーリング サーチ スペースと元の着信者は次のとおりです。
この関数は、FAC または CMC のどちらかまたは両方が必要な指定された宛先に、コールをブラインド転送します。この関数用に Cisco Unified TSP で使用されるコーリング サーチ スペースと元の着信者は次のとおりです。
SIP を実行している電話機の CTI のサポートの一環として、TSP では、新しい SIP 機能である Refer と Replace をサポートしています。Refer、Replace 指定の Refer、Replace 指定の Invite は、それぞれ別のコール制御機能を開始する別々のメカニズムです。たとえば SIP 用語での「Replace 指定の Refer」とは、Unified CM での転送操作に相当します。Replace 指定の Invite は複数の SIP トランクにわたるピックアップ コール機能に使用できます。TSP は、SIP を実行している Unified CM 電話機や SIP を実行しているサードパーティの電話機によって開始される機能に対応したイベント ハンドリングをサポートします。TSP では、API からの Refer または Replace の要求開始はサポートされません。TAPI には、Refer および Replace 機能に関連した理由コードが定義されていないため、標準の TAPI 理由コードの、LINECALLREASON_UNKNOWN が返されます。アプリケーションが 0x00070000 以上の拡張機能バージョンをネゴシエートした場合、LINE_CALLINFO::dwDevSpecificData の一部として新しいコール理由が TSP からユーザに提供されます。
ダイアログ内参照では、TSP は Referrer を、拡張コール理由 CtiCallReasonRefer で LINECALLSTATE_UNKNOWN | CLDSMT_CALL_WAITING_STATE コール状態にします。これで、アプリケーションがこのコールで他のどのコール機能も呼び出せないなどの、Referrer のコール レッグを表示できます。LINECALLSTATE_UNKNOWN | CLDSMT_CALL_WAITING_STATE のときのこのコールのすべての要求には、LINEERR_INVALCALLSTATE というエラーが返ります。
Referrer は Refer 要求の開始後にこのコールをクリアする必要があります。Referrer がコールを終了しない場合、参照に成功すると、Refer 機能によってこのコールがクリアされます。LINECALLSTATE_IDLE が拡張理由 CtiCallReasonRefer で報告されます。
Referrer がコールを終了しない場合に Refer 要求に失敗すると(たとえば Refer To Target がビジーのとき)、Refer 機能によって Referrer と Referee の間のコールが復元されます。
SIP を実行している Unified CM 電話機を使用すると、Unified CM はすべての既存のコール機能を透過的にして、電話機が、Unified CM の既存の機能と同じ動作の SIP 機能を呼び出したときに、アプリケーションが既存のイベントを受け取れるようにします。たとえば、Replace 指定の Refer が、Unified CM クラスタ内で(同じ SIP 回線上のプライマリとセカンダリの両方のコンサルト コール レッグ付きの)SIP を実行する電話機に呼び出されたとき、すべてのイベントが転送機能と同様に報告されます。
ゲートウェイまたはトランクでコールが転送されたときの、SIP183 メッセージに対する応答方法について、Cisco TAPI を更新しました。確立されたコールがトランク経由で転送され、SIP 183 を受信すると、Cisco TAPI は RINGBACK 状態を報告します。このコールに応答があると、Cisco TAPI は、CONNECTED 状態を報告します。
この機能を設定するため、新しい Cisco CallManager サービス パラメータ、SDP による SIP 183 の CTI レポートのリングバック(CTI Report Ringback on SIP 183 with SDP)を追加しました。このサービス パラメータを True に設定すると、上記の動作が適用されます。これがデフォルトの設定です。
アプリケーションが従来の動作を使用する必要がある場合、サービス パラメータを False に設定できます。この設定では、ゲートウェイまたはトランクでコールを転送すると、Cisco Unified Communications Manager が SIP 183 を受信したときに PROGRESSING 状態を Cisco TAPI に報告しますが、接続が確立しても、Cisco TAPI は CONNECTED 状態を報告しません。
6.0(1) よりも前のリリースでは、各コールのセキュリティ状態は、電話機とそれに直接接続されている通話者間のコールの状態に一致していました。電話会議の場合、これは会議ブリッジに相当します。以前のリリースでは、セキュリティ保護された会議リソースが存在しなかったため、セキュアな電話会議は不可能でした。
リリース 7.0(1) では、セキュア会議を実現するために、セキュリティ保護された会議リソースがサポートされています。セキュア会議機能を使用すると、会議ブリッジを非セキュア モードまたは暗号化シグナリング/メディア モードのいずれかに設定できます。ブリッジを暗号化シグナリング/メディア モードに設定すると、セキュアなメディア リソースとして Cisco Unified Communications Manager に登録されます。これにより、ユーザはセキュアな会議セッションを作成できるようになります。すべての会議参加者のメディア ストリームが暗号化されている場合、その会議は暗号化モードとなります。そうでない場合、その会議は非セキュア モードとなります。
会議全体のセキュリティ状態は、その会議に参加しているコールの中で最もセキュリティの低いコールに基づいて決定されます。たとえば、通話者 A(セキュア)、通話者 B(セキュア)、および通話者 C(非セキュア)が会議に参加しているとします。会議ブリッジで暗号化 SRTP がサポートされていて、A および B との通信に SRTP が使用されている場合でも、C の電話機は非セキュアです。したがって、会議全体のセキュリティ状態は非セキュアとなります。会議全体のセキュリティ状態は非セキュアですが、割り当てられた会議ブリッジはセキュアであるため、セキュアな電話機(この場合は A および B)は SRTP キーを受信します。TSP は、各参加者にコール全体のセキュリティ状態を通知します。会議全体のコール セキュリティ レベルは LINECALLINFO の DEVSPECIFIC 部分を使用してアプリケーションに通知されます。これにより、その電話会議が暗号化されているかまたは非セキュアであるかが示されます。
セキュア会議機能では、コールのセキュリティ状態を示すために次の 4 つのフィールドが使用されます。
DWORD CallSecurityStatusOffset; DWORD CallSecurityStatusSize; DWORD CallSecurityStatusElementCount; DWORD CallSecurityStatusElementFixedSize;
typedef struct CallSecurityStatusInfo { DWORD CallSecurityStatus; } CallSecurityStatusInfo;
コール中にセキュアな通話者や非セキュアな通話者が会議に参加し、あるいは退席して全体のコール セキュリティ状態が変化すると、LINECALLINFO が更新されます。
会議開催者には、開催者のセキュリティ能力に応じて会議リソースが割り当てられます。同等のセキュリティ能力の会議リソースを割り当てることができない場合、既存の機能を維持するために、システムはセキュリティ度の低い会議リソースを割り当てます。
セキュア会議で共有回線が使用されている場合、回線が RIU(リモートで使用中、Remote in Use)モードになっている側の電話機には、コールのセキュリティ状態が表示されません。ただし、アプリケーションに対しては、非アクティブなコールに関するその他のコール情報とともに、全体的なセキュリティ状態が TSP から通知されます。したがって、TSP は、すべての RIU 回線に対しても OverallSecurityStatus をレポートします。このステータスは、アクティブな回線にレポートされるステータスと同じです。アプリケーションでは、エンド ユーザに対してこの情報を提供するかどうかを決定できます。
セキュア RTP(SRTP)機能を使用すると、Cisco TSP で SRTP 情報をアプリケーションに報告したり、デバイス登録中に SRTP アルゴリズム ID を指定できます。Cisco TSP から提供される SRTP 情報には、マスター キー、マスター ソルト、algorithmID、isMKIPresent、および keyDerivation があります。これらのキー情報を受信するには、管理者は Cisco Unified Communications Manager の管理ユーザのウィンドウで TLS Enabled フラグと SRTP Enabled フラグを設定し、TSP と CTIManager の間で TLS リンクを確立する必要があります。
一方、アプリケーションはデバイスの登録時に、メディアがアプリケーションによって終端される場合に備えて、CTI ポートと CTI ルート ポイント用の SRTP アルゴリズム ID を提供することができます。アプリケーションでは、0x80070000 バージョン以降がネゴシエートされた LineOpen を呼び出したあとに、Line_devSpecific - CCiscoLineDevSpecificUserSetSRTPAlgorithmID の新規の Cisco 拡張版を使用して、サポート対象の SRTP アルゴリズム ID を設定し、TSP が CTI Manager 上にデバイスをオープンできるように、後に CCiscoLineDevSpecificUserControlRTPStream または CCiscoLineDevSpecificPortRegistrationPerCall を続けます。
オープンした回線に着信した場合、TSP は LINE_CALLDEVSPECIFIC イベントをセキュア メディア インジケータでアプリケーションに送信してから、アプリケーションで LINECALLINFO を照会して、SRTP 情報が使用可能であれば SRTP 情報の詳細を得ることができます。SRTP 情報は、LINECALLINFO 構造体の DevSpecific 部分にあります。
コール中のモニタリングの場合、セキュア メディア インジケータとともに LINE_CALLDEVSPECIFIC が Cisco TSP により送信されます。ただし、この場合に取得できる SRTP 情報はありません。アプリケーションの要求が、CPDST_REQUEST_RTP_SNAPSHOT_INFO メッセージ タイプの PhoneDevSpecific を介して出されたときだけ、イベントが送信されます。
スタティック登録を使用して SRTP をサポートするため、遅延したデバイスまたは回線に一般メカニズムが導入されました。適用されるものは次のとおりです。
拡張バージョン ビット SELSIUSTSP_LINE_EXT_VER_FOR_DELAYED_OPEN = 0x40000000
CiscoLineDevSpecificType -SLDST_SEND_LINE_OPEN
CCiscoLineDevSpecific -CciscoLineDevSpecificSendLineOpen
アプリケーションが、CTI ポートに対して LineOpen の 0x00070000 とネゴシエートする場合、TSP はすぐに LineOpen/DeviceOpen を実行します。アプリケーションが、CTI ポートに対して LineOpen の 0x40070000 とネゴシエートする場合、TSP は LineOpen/DeviceOpen を遅延します。CCiscoLineDevSpecificUserSetSRTPAlgorithmID(SLDST_USER_SET_SRTP_ALGORITHM_ID)を使用すると、アプリケーションで SRTP アルゴリズム ID を指定できます。ただし、TSP で実際のデバイスや回線のオープンを起動させるには、アプリケーションから CCiscoLineDevSpecificSendLineOpen(SLDST_SEND_LINE_OPEN)を送信する必要があります。
アプリケーションが、CTI ポートや RP に対して LineOpen の 0x80070000 とネゴシエートする場合、アプリケーションで CCiscoLineDevSpecific にメディア情報が指定されるまで、TSP は LineOpen/DeviceOpen を遅延します。ただし、アプリケーションではメディア情報を指定する前に、CCiscoLineDevSpecificUserSetSRTPAlgorithmID (SLDST_USER_SET_SRTP_ALGORITHM_ID) を使用して SRTP アルゴリズム ID を指定することができます。
アプリケーションが RP に対して LineOpen の 0x40070000 とネゴシエートする場合、RP がアプリケーションによってメディアを終端させる必要があるため、TSP は CCiscoLineDevSpecificUserSetSRTPAlgorithmID (SLDST_USER_SET_SRTP_ALGORITHM_ID) 要求に失敗します。
現在、SELSIUSTSP_LINE_EXT_VER_FOR_DELAYED_OPEN ビットは、メディアの終端に TSP Wave ドライバを使用しているときに CTI ポートだけで使用されます。会議の場合には、両側の親の電話会議に SRTP 情報が格納されます。会議の場合、適切なバージョンとネゴシエートする、SRTP 情報に関係するアプリケーションは、会議の特定の側の CENNECTED 状態のコールから SRTP 情報を取得します。
CCiscoLineDevSpecificUserSetSRTPAlgorithmID が定義されます。
CCiscoLineDevSpecific 拡張機能の CCiscoLineDevSpecificSendLineOpen が定義されます。アプリケーションのネゴシエートされたバージョンがこの機能をサポートしている場合、新しい LINE_CALLDEVSPECIFIC イベントが送信され、既存の RTP パラメータも LINE_CALLDEVSPECIFIC イベントで送信されます。
Wave ドライバ(メディア終端のエンドポイント)は srtp_policy を使用して crypto コンテキストを作成します。これは、IPPhones や CTIPorts で送受信された暗号化および複合化パケットと一致していなければなりません。電話機では、SIP を使用する電話機を含むすべての電話機のタイプに 1 つのハードコードされた srtp_policy を使用します。
policy->cipher_type = AES_128_ICM;
policy->auth_type = HMAC_SHA1;
policy->sec_serv = sec_serv_conf_and_auth;
(注) | アプリケーションではキー情報を保存せず、適切なセキュリティ方式を使用してキー情報の機密性を確保しなければなりません。キー情報が処理された後は、アプリケーションでメモリをクリアする必要があります。また、データ(SRTP)を暗号化するメカニズムを提供する際に、アプリケーションによってコントロールがエクスポートされる場合があります。そのため、アプリケーションでエクスポート クリアランスを行う必要があります。 |
CTIManager との間にセキュアな接続を確立すると、アプリケーションのユーザは Cisco TSP の UI を使ってより多くの情報を設定できます。この情報によって、TSP は自身のクライアントの証明書を作成できます。この証明書は、TSP と CTIManager との間に相互認証のセキュア チャネルを作成するのに使用されます。
TSP の UI では [セキュリティ(Security)] という名前の新しいタブが追加され、このタブ上で次のようなオプションが利用できます。
[CTIManager へのセキュア接続(Secure Connection to CTIManager)] チェックボックス:チェックされている場合、TSP は TLS CTIQBE ポート(2749)を通じて接続します。チェックされていない場合、TSP は CTIQBE ポート(2748)を通じて接続します。
デフォルトの設定は非セキュア接続で、このチェックボックスはチェックされていません。
また、TSP ユーザのセキュリティ フラグは Cisco Unified Communications Manager Administration で有効にする必要があります。CTIManager は、TLS で接続しているユーザにセキュア アクセスが許可されているかどうかを調べる検証チェックを実行します。CTIManager は、セキュリティが有効なユーザにだけ TLS ポート 2749 への接続を許可し、非セキュア ユーザにだけ CTIQBE ポート 2748 への接続を許可します。
セキュリティを有効にするユーザ フラグは、クラスタ セキュリティ モードによって決まります。クラスタ セキュリティ モードがセキュアに設定されていればユーザのセキュリティ設定に意味がありますが、それ以外の場合は接続を非セキュアにする必要があります。CTIManager のセキュア接続がチェックされると、次の設定が編集可能になります。
CAPF サーバ:クライアントの証明書を取得する CAPF サーバの IP アドレス。
CAPF ポート(デフォルト:3804):証明書をダウンロードするために接続する CAPF サーバのポート。
認証コード(AuthCode):クライアント マシンでの CAPF サーバおよびプライベート キー ストレージを使用したクライアント認証に必要です。
インスタンス ID(IID):CTIManager への各セキュア接続には、認証用に、自身の証明書がなければなりません。接続ごとに異なる証明書を持つという制限により、証明書を要求しているのが適切な AuthCode と IID を持つユーザかどうかが CAPF サーバで確認されなければなりません。CAPF サーバは、AuthCode と IID を使用してユーザの ID を確認します。CAPF サーバは、1 つの AuthCode で証明書を要求するアプリケーションのインスタンスを 1 つに制限するため、証明書を発行すると AuthCode をクリアします。CCM 管理者はユーザ設定で複数の IID および AuthCode を提供できるようにします。
TFTP サーバ:CTL ファイルを取得する TFTP サーバの IP アドレス。CTL ファイルはサーバ証明書を確認するために必要であり、TLS 接続を相互認証する間に送信されます。
[証明書の取得(Fetch Certificate)] チェックボックス:この設定は保存されません。オンにした場合はクライアントの証明書を更新するのに使用され、設定は自動的にクリアされます。
[証明書取得の再試行回数(Number of Retries for Certificate Fetch)]:証明書ダウンロードのための CAPF サーバへの接続がエラーになる場合に TSP が接続を再試行する回数を示します(デフォルト:0)(範囲:0~3)。
[証明書取得の再試行間隔(Retry Interval for Certificate Fetch)]:試行が設定されている場合に使用されます。再試行の間 TSP が待機する時間(秒)を示します(デフォルト:0)(範囲:0~15)。
クライアント証明書が変化するたびにユーザがそれを更新するとは限らないので、ユーザがこのボックスにチェックマークを入れると、TSP UI が"これによりセキュリティ証明書の更新が開始されます(This will trigger a certificate update)"というメッセージを表示します。"今すぐ TSP 証明書を更新することを確認します。"これは、ユーザが誤ってこのチェックボックスを選択していないか確認するためです。有効な証明書が取得できないと、TSP は CTIManager とのセキュア接続の確立に失敗します。CTIManager への各セキュア接続には、認証用に一意の証明書が必要です。
アプリケーションが同じ証明書で同時に複数のプロバイダーを作成しようとした場合や、同じ証明書によってセッションがすでに存在していたりオープンしていたりした場合は、両方のプロバイダーが CTIManager によって切断されます。TSP は、プロバイダーをインサービスにするため、CTIManager との再接続を試みます。しかし、両方のプロバイダーが、重複した同一の証明書を使用して継続的に接続を試行した場合は、両方のプロバイダーが、一定回数の再試行の後にクローズされ、その証明書は Unified CM サーバ上の CTIManager によって、信頼できないものとしてマークされます。証明書が信頼できないものとしてマークされるまでの試行回数は、CTIManager サービス パラメータの [CTI InstanceId Retry Count] から設定できます。以降、信頼できない証明書を持つプロバイダーをオープンしようとしても、CTIManager によって拒否されます。この場合、信頼できない証明書の CAPF プロファイルは削除され、そのユーザには新しい CAPF プロファイルを作成する必要があります。ユーザの新しい CAPF プロファイルには、新しいインスタンス ID を使用する必要があります。そうでない場合、前に信頼できないものとされた古い証明書が再び使用されるおそれがあります。
エラー コード TSPERR_UNKNOWN の値は 0x00000010 ですが、エラー コード TSPERR_INIT_CERTIFICATE_COMPROMISED が、0x00000011 の値で新規に追加されました。これで、"if (err < TSPERR_UNKNOWN))" より大きい値のエラー コードが存在することになったため、アプリケーションはこのチェックをしません。
TLS が使用されると、公開キー暗号化が頻繁に使用されるため、最初のハンドシェイクが遅くなると予想されます。最初のハンドシェイクが完了してセッションが確立されると、オーバヘッドは格段に小さくなります。次のプロファイリングの結果は、セキュアおよび非セキュアの両方の CTI 接続における ProviderOpen に適用されます。
11.5 リリースより前は、Cisco TSP によって、CTLFile の SHA1 の署名を検証するために使用されるダイジェスト アルゴリズムがハードコーディングされていました。11.5 リリース以降、Cisco TSP は、CTLFile で指定されている DigestAlgorithm タグに基づくダイジェスト アルゴリズムを使用するように拡張されています。このようにして、Cisco TSP は SHA1 または SHA512 で署名された CTLFile を検証します。
この機能は、セキュアな環境で、コールのサイレント モニタリングおよび録音を行う機能を向上させます。Cisco Unified Communications Manager(Cisco Unified CM)、リリース 8.0(1) では、Cisco Unified CM ソフトウェアの機能が拡張され、コール モニタリングと録音がセキュア環境で行えるようになりました。したがって、セキュアなコールのモニタリングや録音が可能です。
録音セッションやモニタリング セッションは、スーパーバイザ/録音デバイスおよびエージェントがセキュア機能を備えている場合のみセキュア モードで開始できます。録音/モニタリング要求は、スーパーバイザ/録音デバイスが、エージェントのセキュリティ機能を超えるまたは適合する場合のみ、正常に実行できます。
TransactionID(モニタリング セッションに一意)は、スーパーバイザまたはエージェントのコールに関する Call Info の DevSpecific 部分にある Call Attribute 情報で、アプリケーションに公開されます。
スーパーバイザ セキュリティ機能がエージェントの機能以上でないために、サイレント モニタリング セッションが使用できない場合、Param1 = SLDSMT_MONITORING_TERMINATED を指定して LINE_DEVSPECIFIC イベントが配信され、Monitoring Terminated イベントおよび終了されたコールの Param2 = TransactionID を示します。
Monitoring Terminated イベントを受信するには、lineDevSpecific SLDST_SET_STATUS_MESSAGES 要求を使用して、DEVSPECIFIC_SILENT_MONITORING_TERMINATED メッセージ フラグをアプリケーションに設定する必要があります。
アプリケーションは、Monitoring Session Terminated イベントの LINE_DEVSPECIFIC イベントで TSP が提供する TransactionID に基づいて、終了するモニタリング セッションを判断する必要があります。
Monitoring Terminated イベントは、モニタリング セッションを開始要求したが、モニタリング コールに参加できなかったスーパーバイザに配信されます。
録音:Cisco Unified CM は、認証済みのデバイスでの録音、および認証された録音デバイスへの録音をサポートしていません。
モニタリング/録音セッション開始後に、アプリケーションがカスタマー、エージェント、およびスーパーバイザ回線をモニタリングする場合、カスタマーとエージェント間の直接コールの CallReason は、LINECALLREASON_UNKNOWN となります。スーパーバイザのモニタリング コールでは、CTI がそれぞれの機能について、CallReason = CtiReasonSilentMonitoring/ CtiReasonRecording を報告しているので、CallReason は、LINECALLREASON_DIRECT となります。
(注) | モニタリング対象のコールが、2 人のスーパーバイザによる会議電話になっている場合、スーパーバイザのコールの、callinfo の devspecific 部分に入っている CallAttribute 情報は、エージェントがコールをドロップしてもクリアされません。 |
新しいエラー コード:LINEERR_SECURITY_CAPABILITIES_MISMATCH 0xC000000E
既存の原因コード:LINEDISCONNECTMODE_INCOMPATIBLE 0x00000400
新しい LINE_DEVSPECIFIC メッセージ タイプ:SLDSMT_MONITORING_TERMINATED。詳細については、Silent Monitoring Session Terminated イベントを参照してください。
新しい LineDevSpecificSetStatusMessage フラグ:DEVSPECIFIC_SILENT_MONITORING_TERMINATED。詳細については、ステータス メッセージの設定を参照してください。
CallAttributeInfo_ExtA0 フィールドでは、LINECALLINFO::DEVSPECIFIC によって TransactionID フィールドが追加されました。詳細については、詳細(Details)を参照してください。
セキュアなモニタリングおよび録音を参照してください。
ユーザは IP フォンの Select(選択)ソフトキーを使用して、コール インスタンスを選択し、そのコールに対して転送や会議などの機能を呼び出すことができます。回線上のコールを選択すると、そのコールがロックされ、他の共有回線アピアランスからはそのコールを選択できなくなります。すでに選択されているコールに対して再び "[選択(Select)]" キーを押すと、選択が解除されます。
Cisco Unified TSP では、操作の対象となるコールを呼び出すパラメータがすべての転送関数と会議関数に含まれるため、"[選択(Select)]" キーでコールを選択する機能はサポートしていません。
Cisco Unified TSP は、アプリケーションでモニタされている回線上のコールをユーザが選択したことによって発生するイベントをサポートしています。回線上のコールを選択すると、同じライン アピアランスを共有する他のすべての回線で、コール状態が dwCallState=CONNECTED および dwCallStateMode=INACTIVE に変更されます。
次のように、2 つの拡張機能によって、リダイレクト時に元の着信者を設定できるようになりました。
詳細については、lineDevSpecificを参照してください。
Cisco Unified TSP では、同じ DN を共有している 2 本の回線を開くことができます。これらの回線はそれぞれ、共有回線アピアランスと呼ばれます。
Cisco Unified Communications Manager では、同じライン アピアランスを共有している各デバイスに、複数のアクティブ コールが同時に存在できるようになりました。各デバイスで保持できるアクティブ コールの数は現在も 1 つまでに制限されていますが、保留コールまたは着信コールは常に複数保持できます。Cisco Unified TSP を使用して共用ライン アピアランスのモニタと制御を行うアプリケーションでは、この機能をサポートできます。
共有回線アピアランスとして設定されている回線上にアクティブ コールが存在する場合、他の回線から見たそのコールの状態は dwCallState=CONNECTED および dwCallStateMode=INACTIVE になります。実際の IP Phone に通話者情報を表示する機能がない場合でも、Cisco Unified TSP は他の回線上のコールに関する通話者情報をレポートします。したがって、この情報をブロックするかどうかをアプリケーションで決定できます。なお、CONNECTED INACTIVE 状態のコールに対しては、コール制御関数を使用できません。
Cisco Unified TSP は、CTI ルート ポイント デバイスでの共有回線アピアランスの使用をサポートしていません。
複数の共有回線を含む DN にコールが発信された場合、コールを発信した回線の LINECALLINFO 構造体の dwCalledIDName は空になるか、いずれかの共有 DN の名前にランダムに設定されることがあります。その理由は、コールに対して応答があるまで、どの共有 DN にコールが発信されているかを Cisco Unified TSP および Cisco Unified Communications Manager が判断できないからです。
Cisco TSP のインストーラで、コマンド プロンプトからのサイレント インストール、サイレント アップグレード、およびサイレント再インストールがサポートされるようになりました。サイレント インストールでは、ダイアログボックスがまったく表示されません。
サイレント モニタリングとは、エージェントに気づかれずに、エージェントとカスタマーの間の会話をスーパーバイザを聴取できる機能のことです。個々のコールをアプリケーションでモニタするには、各回線の DevSpecific 要求でモニタリング タイプを指定します。モニタリングされる側の通話者とモニタする側の通話者が両方ともユーザ コントロールリストに含まれている必要があります。
アプリケーションでは、CCiscoLineDevSpecificStartCallMonitoring への入力として、不変な lineID(permanentLineId)、モニタリング モード、モニタ トーンの送信方向(toneDirection)を設定する必要があります。サイレント モニタリング モードだけがサポートされており、スーパーバイザからエージェントに話しかけることはできません。
アプリケーションでは、モニタリングを開始するときにトーンを再生するかどうかを指定できます。ToneDirection は、none(トーンを再生しない)、local(エージェントだけにトーンを再生する)、remote(カスタマーとスーパーバイザに対してトーンを再生する)、または local & remote(エージェント、カスタマー、およびスーパーバイザに対してトーンを再生する)に設定できます。
enum PlayToneDirection { PlayToneDirection_LocalOnly = 0, PlayToneDirection_RemoteOnly, PlayToneDirection_BothLocalAndRemote, PlayToneDirection_NoLocalOrRemote };
要求処理が完了すると、その回線で接続状態になっているコールのモニタリングが開始します。これで、スーパーバイザとエージェントの間に新しいコールが発生します。ただし、このコールはビルトイン ブリッジ(BIB)によって自動的に応答されるため、エージェントはこのコールに気づきません。スーパーバイザとエージェントの間に確立されるコールは、一方向音声コールです。スーパーバイザは、エージェントとカスタマーのミクストストリームを聞くことができます。コールがアクティブになるまでは、アプリケーションからはそのコールのモニタリング セッションを開始できません。
スーパーバイザがコール モニタリングを開始すると、TSP からエージェント コールに LINE_CALLDEVSPECIFIC (SLDSMT_MONITORING_STARTED) イベントが送信されます。モニタリングが開始すると、TSP は LINECALLINFO の DEVSPECIFIC 部分で、モニタリング対象の通話者に関するコール属性情報(deviceName、DN、およびパーティション)を、モニタリングしている通話者に提供します。さらに、モニタリングが開始すると、TSP は LINECALLINFO の DevSpecific データを使用して、モニタリングしている側の通話者に関するコール属性情報(deviceName、DN、およびパーティション)を、モニタリングされている側の通話者に提供します。
エージェントかカスタマーのいずれかがコールを終了すると、モニタリング セッションは終了します。また、スーパーバイザがモニタリング コールを切断した場合も、モニタリング セッションは終了します。スーパーバイザがコールを切断すると、TSP からエージェントに LINE_CALLDEVSPECIFIC (SLDSMT_MONITORING_ENDED) が送信されます。エージェントがコールを切断したことによってモニタリング セッションが終了した場合、イベントは送信されません。
SIP を使用する電話機に対する CTI のサポートの一環で、TSP は、CTIManager からデバイスやコールのイベントで受信された SIP URL を提供します。SIP URL は、LINE_CALLINFO::dwDevSpecificData の拡張コール情報構造のそれぞれの対応する通話者に示されます。
コール中に SIP トランクが呼び出されると、通話者情報に DN が表示されない可能性があります。そのため、このようなコールの場合に、アプリケーションでは SIP URL 情報を参照する必要があります。
アプリケーションが 0x00070000 以上の拡張バージョンとネゴシエートした場合、LINE_CALLINFO::dwDevSpecificData の一部として SIP URL 情報が TSP からユーザに提供されます。
スーパー プロバイダー機能によって、TSP アプリケーションはシステム内のすべての CTI 制御可能デバイス(IP Phone、CTI ポート、CTI ルート ポイントなど)を制御できます。TSP アプリケーションには、制御可能なデバイスの割り当て一覧が必要です。この一覧に含まれないデバイスは制御できません。しかしアプリケーションによっては、システム内で非常に多くの(あるいはすべての)CTI 制御可能デバイスを制御する場合もあります。スーパー プロバイダー機能を使用すると、管理者は CTI アプリケーションを"スーパー プロバイダー"として設定できます。これにより、特定のアプリケーションでシステム内のすべての CTI 制御可能デバイスを制御できるようになります。
以前は、スーパー プロバイダー機能を TSP アプリケーションで使用することはできず、TSP アプリケーションではデバイスが制御可能リストに含まれていなければなりませんでした。このリリースでは、CallManager システム内のすべての CTI 制御可能デバイスを TSP アプリケーションで制御できます。スーパー プロバイダー アプリケーションは、オープンの前にそのデバイスを明示的に"取得"(制御権の取得)する必要があります。
TSP からアプリケーションへの新しいインターフェイスを提供し、システム内のすべてのデバイスを明示的に取得または取得解除することが可能です。CTI により QBE を介した SingleGetInfoFetch API を使用して、明示的に得られたデバイスの情報を取得します。その後、TSP は LineInfoFetch API を使用してこのデバイスの回線情報を取得します。このデバイスの回線は、LINE_CREATE/PHONE_CREATE イベントを使用してアプリケーションに報告されます。
アプリケーションは、明示的にデバイスを「取得解除」できます。デバイスの取得解除に成功すると、TSP は LINE_REMOVE/PHONE_REMOVE イベントをアプリケーションに発行します。
TSP では、「Super-Provider」フラグの変更通知もサポートされます。管理者が管理ページでユーザを「スーパー プロバイダー」として設定していた場合、ステータスが変更されてそのユーザがスーパー プロバイダーではなくなると、CTI はそれを ProviderUserChangedEvent で TSP に通知します。
いずれかのデバイスが明示的に取得されてスーパー プロバイダー モードでオープンされていた場合、TSP は PHONE_REMOVE/LINE_REMOVE をアプリケーションに発行して、そのデバイスや回線がアプリケーションで使用できなくなったことを示します。
このリリースでは、TSP は、CallParkDN モニタリングの変更通知もサポートします。たとえば、管理ページでユーザによる CallParkDN モニタリングが許可された設定になっており、フラグの状態が無効になったとします。その後、TSP は CallParkDN に LINE_REMOVE を発行します。
また、最初に CallParkDN モニタリングが無効になっている状態から有効状態に変わったとします。すると、TSP は CTI からすべての CallParkDN を取得し、LINE_CREATE を各 CallParkDN に発行します。
スーパー プロバイダー機能によって、TSP アプリケーションはシステム内のすべての CTI 制御可能デバイス(IP Phone、CTI ポート、CTI ルート ポイントなど)を制御できます。通常、TSP アプリケーションには、制御可能なデバイスの割り当て一覧が必要です。この一覧に含まれないデバイスは制御できません。しかしアプリケーションによっては、システム内で非常に多くの(あるいはすべての)CTI 制御可能デバイスの制御が必要になる場合もあります。
スーパー プロバイダー機能を使用すると、管理者は CTI アプリケーションをスーパー プロバイダーとして設定できます。これにより、特定のアプリケーションでシステム内のすべての CTI 制御可能デバイスを制御できるようになります。
スーパー プロバイダー機能を TSP アプリケーションで使用することはできず、TSP アプリケーションではデバイスが制御可能リストに含まれていなければなりませんでした。リリース 5.1 以降では、Unified CM システム内のすべての CTI 制御可能デバイスを TSP アプリケーションで制御できます。
スーパー プロバイダー アプリケーションは、オープンの前にそのデバイスを明示的に取得(制御権の取得)する必要があります。TSP からアプリケーションへの新しいインターフェイスを提供し、システム内のすべてのデバイスを明示的に取得または取得解除することが可能です。CTI により QBE を介した SingleGetInfoFetch API を使用して、明示的に得られたデバイスの情報を取得します。その後、TSP は LineInfoFetch API を使用してこのデバイスの回線情報を取得します。このデバイスの回線は、LINE_CREATE/PHONE_CREATE イベントを使用してアプリケーションに報告されます。
このアプリケーションは、デバイスを明示的に「取得解除」できます。デバイスの取得解除に成功すると、TSP は LINE_REMOVE/PHONE_REMOVE イベントをアプリケーションに発行します。
TSP では、"Super-Provider" フラグの変更通知もサポートしています。Unified CM の管理で管理者がユーザを"スーパー プロバイダー"として設定していると、このステータスが変更されてそのユーザがスーパー プロバイダーではなくなり、CTI は ProviderUserChangedEvent で TSP に通知します。いずれかのデバイスが明示的に取得されてスーパー プロバイダー モードでオープンされていた場合、TSP は PHONE_REMOVE/LINE_REMOVE をアプリケーションに発行して、そのデバイスや回線がアプリケーションで使用できなくなったことを示します。
リリース 5.1 以降では、TSP は CallParkDN モニタリングの変更通知もサポートします。Unified CM の管理でユーザによる CallParkDN モニタリングを許可するよう設定すると、このフラグのステータスは無効になります。その後、TSP は CallParkDN に LINE_REMOVE を発行します。
CallParkDN モニタリングが無効の場合、ステータスは有効に変わり、TSP は CTI からすべての CallParkDN を取得し、LINE_CREATE を各 CallParkDN に発行します。
このリリースで、CiscoTSP は LineDevCaps::DevSpecific インターフェイスで、コール最大数、ビジー トリガー/回線ラベル、回線インスタンス ID、ボイスメール パイロット番号を提供します。
TSP は、新しいデバイスの情報(IP アドレス(IPv4 および IPv6)と NewCallRollOver/Consult call rollover/Join/DT/JAL/DTAL フラグ)を処理します。このデバイス情報は Device オブジェクトに保存され、PhoneDevCaps::DevSpecific を使用して提供されます。また、LineDevCaps::DevSpecific を使用して Line App にも提供されます。
NewCallRollOver/Consult call rollover/Join/DT/JAL/DTAL フラグには、デバイス設定とアプリケーション動作を示す 2 つの情報のセットがあります。
TAPI は、上記の情報に何らかの変更があった場合に LineDevSpecific イベントまたは PhoneDevSpecific イベントを使用してレポートします。
コールの最大数(Max Calls)
TAPI は、コール最大数の情報を LineDevCaps::DevSpecific の MaxCalls フィールドで提供します。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_MAX_CALLS ビットがオンになっています。
ビジー トリガー
TAPI は、ビジー トリガーの情報を LineDevCaps::DevSpecific の Busy Trigger フィールドで提供します。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_BUSY_TRIGGER ビットがオンになっています。
回線インスタンス ID
TAPI は、デバイス上に設定された回線インスタンス ID(回線ボタン番号)の情報を LineDevCaps::DevSpecific の LineInstanceNumber で提供します。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_LINE_INSTANCE ビットがオンになっています。
回線ラベル
TAPI は、回線のラベルを LineDevCaps::DevSpecific の LineLabelASCII および LineLabelUnicode の各フィールドで提供します。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_LINE_LABEL ビットがオンになっています。
ボイスメールパイロット
TAPI は、回線上に設定されたボイスメール パイロット番号を LineDevCaps::DevSpecific の VoiceMailPilotDN フィールドで提供します。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_VOICEMAIL_PILOT ビットがオンになっています。
登録済みデバイスの IP アドレスと IP アドレス モード
TAPI は、登録済みデバイスの IP アドレス(IPv4 および IPv6)を PhoneDevCaps::DevSpecific インターフェイスの RegisteredIPv4Address と RegisteredIPv6Address の各フィールド、および LineDevCaps::DevSpecific インターフェイスの RegisteredIPv4Address と RegisteredIPv6Address の各フィールドで提供します。登録済み IP アドレスとともに、RegisteredIPAddressMode インターフェイスで、デバイスが IPv4 または IPv6、あるいは IPv4 および IPv6 で登録されているかどうかが示されます。デバイスが登録されていない場合、RegisteredIPAddressMode の値は IPAddress_Unknown になります。IPAddress_Unknown の場合、RegisteredIPv4Address および RegisteredIPv6Address は参考値としてのみ使用可能です。
デバイス IP アドレスが適用されるのは IP Phone だけで、CTI ポートおよび RP はサポートされていません。情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_DEVICE_IPADDRESS ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_DEVICE_IPADDRESS ビットがオンになっています。
新規コール ロールオーバー:
TAPI は、デバイス上で設定されている新規コール ロールオーバー情報を、PhoneDevCaps::DevSpecific インターフェイスの NewCallRollOverEnabled フラグ、および LineDevCaps::DevSpecific インターフェイスの NewCallRollOverEnabled フラグで提供します。フラグはデバイス用およびアプリケーション用の 2 セットがあります。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_NEWCALL_ROLLOVER ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_NEWCALL_ROLLOVER ビットがオンになっています。
コンサルト コール ロールオーバー:
TAPI は、デバイス上で設定されているコンサルト コール ロールオーバー情報を、PhoneDevCaps::DevSpecific インターフェイスの ConsultCallRollOverEnabled フラグ、および LineDevCaps::DevSpecific インターフェイスの ConsultCallRollOverEnabled フラグで提供します。フラグはデバイス用およびアプリケーション用の 2 セットがあります。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_CONSULTCALL_ROLLOVER ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_CONSULTCALL_ROLLOVER ビットがオンになっています。
同じ回線で参加
TAPI は、デバイス上で設定されている、同じ回線への参加の情報を、PhoneDevCaps::DevSpecific インターフェイスの JoinOnSameLineEnabled フラグ、および LineDevCaps::DevSpecific インターフェイスの JoinOnSameLineEnabled フラグで提供します。フラグはデバイス用およびアプリケーション用の 2 セットがあります。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_JOIN_ON_SAME_LINE ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_JOIN_ON_SAME_LINE ビットがオンになっています。
Join Across Line(回線をまたいで参加)
TAPI は、デバイス上で設定されている、複数ライン同時通話機能の情報を、PhoneDevCaps::DevSpecific インターフェイスの JoinAcrossLineEnabled フラグ、および LineDevCaps::DevSpecific インターフェイスの JoinAcrossLineEnabled フラグで提供します。デバイス用およびアプリケーション用にフラグが 2 セットあります。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_JOIN_ACROSS_LINE ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_JOIN_ACROSS_LINE ビットがオンになっています。
同じ回線での直接転送
TAPI は、デバイス上で設定されている、同じ回線での直接転送の情報を、PhoneDevCaps::DevSpecific インターフェイスの DirectTransferSameLineEnabled フラグ、および LineDevCaps::DevSpecific インターフェイスの DirectTransferSameLineEnabled フラグで提供します。フラグはデバイス用およびアプリケーション用の 2 セットがあります。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_DIRECTTRANSFER_ON_SAME_LINE ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_DIRECTRANSFER_ON_SAME_LINE ビットがオンになっています。
回線をまたいで直接転送
TAPI は、デバイス上で設定されている、回線をまたいで直接転送の情報を、PhoneDevCaps::DevSpecific インターフェイスの DirectTransferAcrossLineEnabled フラグ、および LineDevCaps::DevSpecific インターフェイスの DirectTransferAcrossLineEnabled フラグで提供します。デバイス用およびアプリケーション用にフラグが 2 セットあります。
情報が変更されると、TSP は LineDevSpecific イベントをレポートします。このとき、param1 = SLDSMT_LINE_PROPERTY_CHANGED、param2 は LPCT_DIRECTTRANSFER_ACROSS_LINE ビットがオンになっています。電話機アプリケーションの場合、TSP は PhoneDevSpecific イベントをレポートします。このとき、param1 = CPDSMT_PHONE_PROPERTY_CHANGED_EVENT、param2 は PPCT_DIRECTRANSFER_ACROSS_LINE ビットがオンになっています。PHONE_PROPERTY_CHANGED_EVENT を受信するには、アプリケーションが CCiscoPhoneDevSpecificSetStatusMsgs を使用して DEVSPECIFIC_DEVICE_PROPERTY_CHANGED_EVENT ビットを設定する必要があります。
前述の変更通知イベントの場合、イベントは回線またはデバイスがオープンの場合に限り(Cisco TSP が TAPI レイヤにイベントを送信しても)、TAPI レイヤによってアプリケーションに配信されます。回線またはデバイスがオープンでない場合は、アプリケーションで LineGetDevCaps を再度コールして回線/デバイスに関する最新情報を取得する必要があります。この機能に対して、新しい拡張 0x00090001 を開くか、ネゴシエートする必要があります。
LINEDEVCAPS、回線プロパティ変更イベント、およびステータス メッセージの設定を参照してください。
Cisco Unified IP Phone 6900 および 9900 シリーズのサポートの使用例を参照してください。
この機能を使用すると、ユーザは、100 を超える電話番号をデバイスに関連付けることができます。TSP は、この機能をサポートし、対応する回線をアプリケーションに表示します。
Cisco Unfied IP Phone 7900 シリーズには次のソフトキーが追加されています。
[切替(Swap)] ソフトキーは、転送機能または会議機能を使用する場合だけ使用できます。[切替(Swap)] を押すと、電話機はコンサルト コールを保留し、プライマリ コールを再開します。スワップ操作はプライマリ コールとコンサルト コールの間のリンクを解除しますが、転送操作や会議操作は引き続き可能です。
転送操作の完了前に [キャンセル(Cancel)] を押すと、TSP は CTI からイベント通知を受け取り、保留中の転送要求と会議要求をすべてキャンセルします。
スワップ操作では、プライマリ コールの状態が CONNECTED に変更され、コンサルト コールの状態が ONHOLD に変更されます。
キャンセル操作では、プライマリ コールの状態が ONHOLD に変更され、コンサルト コールの状態は CONNECTED のままになります。
スワップまたはキャンセル操作の後に転送操作を完了する場合、アプリケーションは LineCompleteTransfer または CCiscoLineDevSpecificDirectTransfer を呼び出します。
スワップまたはキャンセル操作の後に会議操作を完了する場合、アプリケーションは Cisco Join API – CCiscoLineDevSpecificJoin を呼び出します。
スワップおよびキャンセル機能を使用する場合、Cisco Unified IP Phone は打診転送やコンサルト会議の呼び出し時にプライマリ コールとコンサルト コールの間の打診関係を制御します。
ユーザがスワップ操作を実行すると、動作は同じですがコールが再開され、保留中のすべての転送操作と会議操作がキャンセルされます。ユーザは打診転送やコンサルト会議のトランザクション中にスワップや切り替えを行うことができます。また、トランザクション中にコール セッション間でスワップや切り替えを行うことができます。
Refer および Replaces のシナリオを参照してください。
警告 | 会議の場合にコールが正しく終了されない場合があるため、TSP ではトランスレーション パターンがサポートされていません。アプリケーションでは、正しく終了されなかったコールを削除するためにコールを消去するか、回線を閉じて再オープンする必要があります。 |
Cisco TSP は、Unicode 文字セットをサポートしています。TSP は、すべてのコール イベントで Unicode の通話者名をアプリケーションに送信します。この通信者名は Communications Manager Administration に設定する必要があります。このサポートは通話者名だけに限定されます。アプリケーションにはロケール情報も送信されます。Unicode の UCS-2 エンコーディングが使用されます。
通話者名は、LINECALLINFO 構造体の DevSpecific 部分にあります。SIP コールの場合、SIP トランクを介して SIP プロキシから Unified CM にコールが返って来ますが、SIP には ASCII と Unicode の両方を実装する方法がないので、ASCII 名だけが渡されます。その結果、接続先およびリダイレクションの Unicode 名は、空白のままアプリケーションに報告されます。
無制限版の Cisco Unified Communications Manager では、暗号化は永続的に無効になります。広く流通している制限版の Cisco Unified Communications Manager では、シグナリングおよびメディア暗号化を設定できます。無制限版から制限版の Cisco Unified Communications Manager へのアップグレードはサポートされていません。管理者は、セキュリティ グループとロール("Standard CTI Secure Connection" と "Standard CTI Allow Reception of SRTP Key Material")で新しいロールを作成することはできません。これらのロールは、無制限版の Cisco Unified Communications Manager では使用できないためです。
(注) | 無制限版から制限版へのアップグレードはサポートされていません。 |
制限版から無制限版の Cisco Unified Communications Manager へアップグレードした場合、すべてのセキュリティ機能が無効になり、エンド ユーザに関連付けられた標準の CTI セキュア ロールが削除されます。ただし、前述の CTI セキュア特権で作成したカスタムの管理ユーザ ロールは、Cisco Unified Communications Manager データベースで有効になります。このような場合、CTIManager が CTI セキュア ロールの情報をフィルタリングするので、アプリケーションは無制限版の Cisco Unified Communications Manager に非セキュア アプリケーションとして接続できます。
また、制限版の Cisco Unified Communications Manager から無制限版の Cisco Unified Communications Manager へアップグレードした後では、セキュアな TAPI アプリケーションは無制限版の Cisco Unified Communications Manager に接続できません。アップグレード後に無制限版の Cisco Unified Communications Manager に接続するには、アプリケーションで TSP UI からのセキュア接続を無効にする必要があります。
アプリケーションが、無制限版の Cisco Unified Communications Manager にセキュア エンドポイントとして CTI ポート/ルート ポイントを登録しようとすると、その要求は失敗します。登録要求に成功する場合もありますが、デバイスはクローズしたままとなり、アプリケーションには失敗が通知されます。
無制限版 Unified CMを参照してください。
Cisco TSP では、宛先アドレスとしてディレクトリ URI を使用したダイヤルがサポートされます。Cisco TSP はディレクトリ URI とディレクトリ番号を区別するのに @ 記号を使用します。@ 記号がある場合は、ダイヤルされたアドレスはディレクトリ URI です。ディレクトリ URI は dwDevSpecificData コール構造体で返すことができるようになりました。
URI ダイヤルは、CTI リモート デバイスでもサポートされています。リモート接続先は、ディレクトリ URI を使用して、リモート接続先番号として設定できます。
次のインターフェイスはディレクトリ URI をサポートするために変更されました。
CiscoTSP は、コールを保留にしたときに、アプリケーションでビデオ ファイルの選択、再生を選択できるように、強化しました。この機能拡張は、Remote Expert ソリューション向けです。新しく追加した contentID は、アプリケーション(TAPI)から CCM にパス スルーします。TAPI はこの値の処理や改変を行いません。contentID は、コールを保留にしたときに再生される VoH ストリームを参照します。
VoH ファイルは外部メディア センス サーバ上に配置されます。保留中ビデオの機能を使用するために、保留中ビデオのサーバを CCM Admin で設定する必要があります。このサーバは、すべての VoH ファイルを格納するメディア センス サーバと一致します。
この機能をサポートするために、新しい CCiscoLineDevSpecific 拡張機能:"CciscoLineDevSpecificHoldEx" を追加しました。
lineHold の拡張機能を参照してください。
LineHold の拡張機能を参照してください。
この機能に下位互換性問題はありません。
サイレント コール モニタリング機能を使用すると、スーパーバイザは、エージェントにモニタリング セッションを検出されることなく、エージェントとカスタマーの間の会話を目立たないように聞くことができます。ウィスパー コーチングは、サイレント コール モニタリングの拡張機能です。ウィスパー コーチングを使用すると、スーパーバイザはモニタリング セッション中にエージェントと対話できます。この機能により、アプリケーションでは、モニタリング コールの現在のモニタリング モードをサイレント モニタリングとウィスパー コーチングの間で切り替えることができます。
ウィスパー コーチング セッションがすでに進行中である場合にアプリケーションが回線をオープンすると、TSP は LineCallInfo::DevSpecific の CallAttributeType フィールドに TSPCallAttribute_WhisperCoachingCall または TSPCallAttribute_WhisperCoachingCall_Target ビットマップのいずれかを設定します。このビットマップは、コールがウィスパー コーチング コールであるか、またはウィスパー コーチング コールのターゲットであるかを示します。
既存の CCiscoLineDevSpecificStartCallMonitoringrequest では、m_MonitorMode パラメータがウィスパー コーチングを示す列挙型をサポートするように拡張されます。
アプリケーションでサイレント モニタリング モードとウィスパー コーチング モードを切り替えられるように、新規の CCiscoLineDevSpecific 拡張である CCiscoLineDevSpecificMonitoringUpdateMode が追加されます。
新規の LineCallDevSpecific イベントによってアプリケーションが更新され、モニタリング モードが変更されたことを示します。
新規の activeToneDirection フィールドが、CallAttributeInfo_ExtA0 構造体に追加されます。このフィールドは、コールに対して再生されているアクティブ トーンの宛先を指定します。
toneDirection の既存のサービス パラメータは、サイレント モニタリング セッションとウィスパー コーチング モニタリング セッションの両方に使用されます。サービス パラメータは、"Play Monitoring Notification Tone To Observed Target(監視対象ターゲットにモニタリング通知トーンを再生)"(ローカルの通話者またはエージェントの場合)と "Play Monitoring Notification Tone To Observed Connected Parties(監視対象の接続済み通話者にモニタリング通知トーンを再生)"(リモートの通話者またはカスタマーの場合)です。
CCiscoLineDevSpecificStartCallMonitoring(モニタリング モード = Silent)または CCiscoLineDevSpecificMonitoringUpdateMode(モニタリング モード = Silent)には、サービス パラメータで設定した toneDirection のほかに、アプリケーションで指定される toneDirection が使用されます。
CCiscoLineDevSpecificStartCallMonitoring(モニタリング モード = Whisper)または CCiscoLineDevSpecificMonitoringUpdateMode(モニタリング モード = Whisper)には、リモート側(カスタマーのみ)に対してアプリケーションで指定される toneDirection が使用されます。この機能では、play toneDirection を設定したサービス パラメータと、リモート側(カスタマーのみ)にトーンを再生するためにアプリケーションで指定された toneDirection を使用します。
次の表は、StartSilentMonitoring/Toggle to SilentMonitoring に対して有効な toneDirection です。
次の表は、Start WhisperCoaching/Toggle to WhisperCoaching に対して有効な toneDirection です。
CSCsb89374 の修正により、CCiscoLineDevSpecificMonitoringUpdateMode を使用する切り替え要求の動作が SIP 電話と SCCP 電話で異なります。CCiscoLineDevSpecificMonitoringUpdateMode が変更された場合:
dwParam1 = 0x30403 represents StartReception dwParam1 = 0x e0500401 represents StartTransmission dwParam1 = 0x4 represents StopReception dwParam1 = 0x2 represents StopTransmission
UpdateMonitorMode、モニタリング モード更新イベント、詳細(Details)、詳細(Details)、および詳細(Details)を参照してください。
Whisper のコーチングを参照してください。
XSI 対応の IP Phone を使用すると、アプリケーションから電話機へ直接接続して、XSI 機能(ディスプレイの操作、ユーザ入力の取得、トーンの再生など)にアクセスすることが可能になります。TAPI には、CTI インターフェイス経由でデバイス データを送信する機能があるので、電話への直接接続を個別に確立して維持しなくても、TAPI アプリケーションから XSI 機能にアクセスできます。この機能は、Cisco Unified TSP のデバイス固有拡張として提供されています。
PhoneDevSpecificDataPassthrough 要求は、IP Phone デバイスに対してのみサポートされます。