- このマニュアルについて
- 概要
- Cisco Unified Communications の概要
- システム コンフィギュレーションの 概要
- 権限とユーザ グループ
- システム レベルのコンフィギュレー ション設定
- クラスタ化
- 冗長化
- コール アドミッション制御
- Resource Reservation Protocol
- Cisco TFTP
- デバイスのサポート
- 自動登録
- ダイナミック ホスト コンフィギュ レーション プロトコル（DHCP）
- ライセンシング
- パーティションおよびコーリング サーチ スペース
- Time-of-Day ルーティング
- ルート プランの概要
- 電話番号の概要
- ダイヤル規則の概要
- ディレクトリの概要
- アプリケーション ユーザと エンド ユーザ
- メディア リソースの管理
- Annunciator
- Conference Bridge
- トランスコーダ
- 保留音
- メディア ターミネーション ポイント
- トランスコーディング、会議 、および MTP 用の Cisco DSP リソース
- ボイスメールの Cisco Unified CallManager への接続性
- SMDI ボイスメールの統合
- Cisco Unity メッセージングの統合
- Cisco DPA の統合
- コール パーク
- コール ピックアップ グループ
- Cisco Unified IP Phone サービス
- Cisco エクステンション モビリティ機能 および電話機へのログイン機能
- Cisco Unified CallManager Attendant Console
- Cisco Unified CallManager Assistant
- Cisco Unified CallManager 音声ゲート ウェイの概要
- IP テレフォニー プロトコルの概要
- セッション開始プロトコル（SIP）の概要
- Cisco Unified CallManager トランク タイプの概要
- Cisco Unified IP Phone
- ビデオ テレフォニーの概要
- コンピュータ テレフォニー統合
- Cisco ATA 186
- 管理ツールの概要
- 索引
Cisco Unified CallManager システム ガイド Release 5.1(3)
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： ルート プランの概要
ルート プランの概要
メニューバーの［ルート プラン］ドロップダウン リストから、ルート パターン、ルート フィルタ、ルート リスト、ルート グループ、ハント パイロット、ハント リスト、および回線グループを使用して Cisco Unified CallManager のルート プランを設定できます。
•
「参考情報」
自動代替ルーティング
Automated Alternate Routing（AAR; 自動代替ルーティング）は、代替番号を使用して、PSTN または他のネットワーク経由でコールを再ルーティングするメカニズムを提供します。AAR 機能のサブセットとして、Cisco Unified CallManager は、ロケーションの帯域幅が不十分であるためにコールをブロックする場合は、PSTN または他のネットワーク経由でコールを自動的に再ルーティングします。AAR を使用すると、発信者が電話を切って着信側にリダイヤルする必要がなくなります。
あるロケーションのデバイスから別のロケーションのデバイスにコールが発信される場合、どちらのロケーションでも、使用可能な最大帯域幅から、そのコールに必要なロケーション帯域幅が差し引かれます。どちらかのロケーションで、そのコールに対してロケーションの帯域幅が不足している場合、Cisco Unified CallManager は、コールをブロックせずに、AAR グループのテーブルと終端電話番号の外部番号を使用して、PSTN または他のネットワーク経由でコールを再ルーティングするための代替番号を提供します。Cisco Unified IP Phone により、「Network congestion, rerouting」というメッセージが表示されます（このメッセージは、Cisco CallManager サービスの［サービス パラメータ設定（Service Parameters Configuration）］を使用して設定します）。Cisco Unified CallManager は、代替番号を使用して、コールを自動的に再ルーティングしようとします。再ルーティングに成功すると、発信者は着信側に接続されます。
AAR は、帯域幅が十分ではない場合に、次のコール シナリオをサポートしています。
• コールが、あるロケーション内の IP Phone の回線または電話番号（DN）から発信され、別のロケーション内の別の IP Phone の回線または DN で終端する。このシナリオには、複数のロケーションに存在する終端 IP Phone デバイスとの共有回線で終端するコール、および Cisco ボイスメール ポートで終端するコールが含まれます。
• あるロケーション内のゲートウェイ デバイスを経由する着信コールが、別のロケーション内の IP Phone の回線または DN で終端する。このシナリオには、複数のロケーションに存在する終端 IP Phone デバイスとの共有回線で終端するコール、および Cisco ボイスメール ポートで終端するコールが含まれます。
Cisco Unified CallManager は、Automated Alternate Routing Enable サービス パラメータが［True］に設定されている場合に限り、帯域幅が十分でないという理由で、PSTN または他のネットワーク経由でコールの再ルーティングを自動的に試行します。PSTN または他のネットワークに接続されているゲートウェイ デバイスにコールをルーティングしようとする場合、Cisco Unified CallManager は、Cisco Unified IP Phone のステーション デバイスおよびゲートウェイ デバイスに割り当てられているデバイスベースの AAR コーリング サーチ スペースを使用します。Cisco Unified CallManager は、回線または DN および Cisco ボイスメール ポートの外部電話番号マスクと電話番号を使用して、コールの再ルーティングに使用される代替番号を導出します。
次のシナリオでは、Richardson AAR グループの回線/DN 5000 が San Jose AAR グループの回線 5001 をコールします。ロケーションの帯域幅が十分でない場合、PSTN または他のネットワーク経由でコールの再ルーティングが試行されます。AAR グループ Richardson から AAR グループ San Jose にコールをルーティングするには、Cisco Unified CallManager が、PSTN または他のネットワークにダイヤルアウトするためのアクセス番号、長距離ダイヤルの要件（ある場合）、および代替番号を認識する必要があります。Cisco Unified CallManager は、AAR ダイヤル プレフィックス マトリックス テーブルから情報を取得します。このテーブルは、発信側回線の AAR グループ値と終端側回線の AAR グループ値によって索引が付けられています。 表17-1 に、回線/DN テーブル内の AAR グループ フィールドのデータ例を示します。
|
|
|
|---|---|
Cisco Unified CallManager は、発信側の回線/DN とゲートウェイ デバイスの AAR グループ値、および終端側の回線と Cisco ボイスメール ポートの AAR グループ値に基づいて、AAR ダイヤル プレフィックス マトリックス テーブルからプレフィックス番号を取得し、導出した代替番号を変換します。 表17-2 に、AAR ダイヤル プレフィックス マトリックス テーブル内のデータ例を示します。
|
|
|
|
|---|---|---|
Cisco Unified CallManager は、AAR ダイヤル プレフィックス マトリックス テーブルから取得したプレフィックス番号を、導出した代替番号の前に付加します。番号分析は、変換された番号と AAR コーリング サーチ スペースを使用して、コールを PSTN または他のネットワークにルーティングします。
ゲートウェイが発信側または終端側のデバイスと同じロケーションにある場合、自動代替ルーティングの成功率は非常に高くなります。したがって、発信側デバイスと同じロケーションにあるゲートウェイから PSTN または他のネットワークに発信し、終端側デバイスと同じロケーションにあるゲートウェイから着信するコールが、最良のシナリオです。他のシナリオの場合は、発信側デバイスと発信ゲートウェイの間、および終端側デバイスと着信ゲートウェイの間で、コールがロケーション帯域幅検証の影響を受けやすい状態になります。
Automated Alternate Routing Enable サービス パラメータ
AAR グループの設定に加えて、クラスタ全体の Automated Alternate Routing Enable サービス パラメータが ［True］ に設定されていることを確認します（このサービス パラメータのデフォルト値は ［False］ です）。
パラメータは、Cisco CallManager サービスのサービス パラメータの［Clusterwide Parameters （System - CCMAutomated Alternate Routing）］セクションに含まれています。
自動代替ルーティングとハント パイロット
以前の Cisco Unified CallManager リリースでは、ボイス メッセージ システムが中央ロケーションにあり、ユーザがリモート ロケーションにいる場合で、リモート ユーザがボイス メッセージ システムへの接続を試行したものの、WAN リンクの帯域幅が使用可能でないとき、ボイス メッセージ システムへのコールを PSTN 経由で再ルーティングできました。
最新の Cisco Unified CallManager リリースでは、AAR はハント パイロットを自動的に処理しません。リモート エージェントの完全修飾電話番号（DN）が不明であるため、AAR は再ルーティングを開始できないからです。
AAR のハント パイロット処理を可能にする［AAR グループ（AAR Group）］と［外線番号マスク（External Number Mask）］の追加フィールドが、［ハント パイロットの設定（Hunt Pilot Configuration）］ウィンドウに表示されます。AAR グループのハント パイロット処理を可能にするには、ハント パイロットごとに、［ハント パイロットの設定（Hunt Pilot Configuration）］ウィンドウでこれらのフィールドを設定する必要があります。詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント パイロットの設定」の章を参照してください。
ルート プランの概説
Cisco Unified CallManager では、Cisco Unified CallManager クラスタ内での内部コールのルーティング、およびプライベート ネットワークまたは PSTN への外部コールのルーティングに対してルート プランを使用しています。
ネットワーク設計は、ルート パターン、ルート フィルタ、ルート リスト、ルート グループ、回線グループ、ハント リスト、およびハント パイロットにより柔軟に行うことができます。ルート パターンは、ルート フィルタと連動して、特定のデバイスにコールを送信したり、特定の番号パターンを組み込んだり、除外したりします。ルート パターンは番号パターンの組み込みと除外に使用します。ルート フィルタは主に番号パターンの組み込みに使用します。ルート リストはルート グループの選択順を制御します。ルート グループはゲートウェイ デバイスの選択順を設定します。
ルート パターンは、ゲートウェイまたはトランクに割り当てるか、ルート グループを含んだルート リストに割り当てることができます。ルート グループは、ゲートウェイとトランクの使用優先順位を決定します。ルート グループにより、使用中のデバイスまたは障害デバイスから、代替デバイスへのオーバーフローが可能になります。
ルート リストは、ルート グループの使用優先順位を決定します。ルート リストを設定する場合、少なくとも 1 つのルート グループを設定する必要があります。1 つまたは複数のルート リストが、1 つまたは複数のルート グループを指すことができます。
ルート フィルタは、ルート パターンにより許可されている特定の番号のルーティングを制限します。タグが、ルート フィルタの中心コンポーネントです。タグは、ダイヤルされた番号の一部に名前を適用します。たとえば、NANP 番号 972-555-1234 には、LOCAL-AREA-CODE (972) タグ、OFFICE-CODE (555) タグ、および SUBSCRIBER (1234) タグが含まれています。
（注） NANP は、米国とその統治領、カナダ、バミューダ、およびカリブ海周辺諸国での PSTN 用の番号方式です。NANP には、北米で認識されるダイヤル可能な番号が組み込まれています。
ルート パターンは、すべての有効な番号ストリングを表します。Cisco Access Analog Trunk Gateway、Cisco Access Digital Trunk Gateway、Cisco MGCP ゲートウェイ、H.323 準拠のゲートウェイ、およびトランクも、ルート パターンを使用します。Cisco Unified CallManager が隣接システムに番号を渡す前に、Cisco ゲートウェイは複雑な制約を使用して一連の番号をルーティングしたり、電話番号を操作したりできます。隣接システムには、central office（CO; セントラル オフィス）、PBX、または別の Cisco Unified CallManager システム上のゲートウェイが含まれます。
回線グループは、DN のリストで構成されます。回線グループは、回線グループのメンバーの分散アルゴリズム（Top Down など）を指定します。また、回線グループは、回線グループのメンバーが応答しない、使用中、または使用できない場合に使用するハント オプションも指定します。Cisco Unified CallManager のリリース 4.1 からは、電話番号が複数の回線グループに属することができます。
ハント リストは、回線グループの順序付きグループで構成されます。回線グループは、複数のハント リストに属することができます。ハント リストがコールを受け入れるには、ハント リストが少なくとも 1 つの回線グループを指定する必要があります。
ハント パイロットは、ハンティングに使用されるルート パターンを示します。ハント パイロットは、パーティション、番号計画、ルート フィルタ、およびハント転送の設定を指定できます。ハント パイロットは、ハント リストを指定する必要があります。
ルート グループとルート リスト
ルート グループには 1 つまたは複数のデバイスが含まれ、ルート リストには 1 つまたは複数のルート グループが含まれます。Cisco Unified CallManager では、同一のルート グループに組み込めるゲートウェイと同一のルート リストに組み込めるルート グループを制限できます。ルート グループとルート リストの制限のため、Cisco Unified CallManager はゲートウェイを次の 3 つのタイプに分けています。
• タイプ 1：MGCP QSIG ゲートウェイ、および QSIG 対応のクラスタ間トランク
• タイプ 2：MGCP 非 QSIG、Skinny、T1-CAS ゲートウェイ、非 QSIG クラスタ間トランク
• タイプ 3：H.225 および H.323 ゲートウェイ、その他すべてのトランク タイプ
ルート リストには、ルート グループのタイプを混合して組み込むことができます。ただし、H225 トランクとタイプ 1（QSIG）ルート グループを組み合せることはできません。Cisco Unified CallManager では、H.323 または H.225 プロトコル（タイプ 3）を使用するゲートウェイを含むルート グループと QSIG プロトコル（タイプ 1）を使用する MGCP ゲートウェイを含むルート グループを同じルート リストに追加することはできません。図17-1 に示すように、タイプ 1 のルート グループとタイプ 2 のルート グループの任意の組み合せ、およびタイプ 2 のルート グループとタイプ 3 ルート グループの任意の組み合せで、ルート リストを作成できます。
ルート グループの作成の詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート グループの設定」を参照してください。ルート リストの作成の詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート リストの追加」を参照してください。
（注） Cisco Unified CallManager のリリース 4.1 の時点では、ルート グループと回線グループを組み合せることはできず、ハント リストは個別のエンティティになっています。したがって、ルート グループはルート リストを構成し、回線グループはハント リストを構成します。Cisco Unified CallManager のリリース 4.0 では、ルート グループと回線グループの両方をルート/ハント リストのコンポーネントにすることができました。
（注） Cisco Unified CallManager のリリース 4.0 では、回線グループとルート グループの両方をルート/ハント リストのメンバーにすることができました。Cisco Unified CallManager のリリース 4.1 では、既存のルート/ハント リストのメンバーとして回線グループが含まれる場合、Cisco Unified CallManager はそのルート/ハント リストをハント リストに移行します。
ルート パターン
Cisco Unified CallManager では、内部コールと外線の両方のルーティングまたはブロックにルート パターンを使用しています。
（注） リリース 4.1 より前の Cisco Unified CallManager では、ルート パターンとハント パイロットが統合されていたため、ルート パターンとハント パイロットの設定を 1 つのウィンドウで行っていました。ルート リストとハント リストは同じリストの一部でした。リストは、回線グループとルート グループの両方またはいずれか一方を含むことができました。
（注） リリース 4.1 からは、ルート グループとルート リストがルート パターン設定の一部となっています。回線グループとハント リストは、ハント パイロット設定の一部です。ルート パターンとハント パイロットは別々に設定します。ルート グループまたはルート リストをハント パイロットおよび回線グループに追加することはできません。ハント リストをルート パターンに追加することはできません。既存のルート パターン/ハント パイロットがハント リストに関連付けられている場合、Cisco Unified CallManager は、そのルート パターン/ハント パイロットをハント パイロットに移行します。
最も単純なルート パターンでは、1 桁以上の数字がセットとして指定されています。たとえば、電話番号の 8912 は、ルート パターンとして指定されます。
また、ゲートウェイと Cisco Unified IP Phone は、ワイルドカードを指定する、より複雑なルート パターンも使用できます。ワイルドカードは番号の範囲を表します。たとえば、X は 0 ～ 9 の任意の数字を示します。
コールを OnNet または OffNet として分類するために、管理者は［ルート パターンの設定（Route Pattern Configuration）］ウィンドウで［コールの分類（Call Classification）］フィールドをそれぞれ［OnNet］または［OffNet］に設定できます。管理者は、［ルート パターンの設定（Route Pattern Configuration）］ウィンドウで［デバイスの上書きを許可（Allow Device Override）］チェックボックスをオンにすることにより、ルート パターンの設定を上書きして、トランクまたはゲートウェイの設定を使用できます。
［ルート パターンの設定（Route Pattern Configuration）］ウィンドウの［ISDNネットワーク固有ファシリティの情報要素（ISDN Network-Specific Facilities Information Element）］セクションでフィールドを設定することにより、ルート パターンを使用して、コールごとにネットワーク固有のサービスまたはファシリティを起動できます。Cisco Unified CallManager は、ユーザがルート パターンをダイヤルするときに、ネットワーク固有のサービスまたはファシリティを使用します。
（注） Cisco Unified CallManager は、PRI プロトコル ゲートウェイだけにネットワーク固有の情報を使用します。H.323 ゲートウェイは、ネットワーク固有のファシリティをサポートしていません。ただし、ダイヤル ピアが適宜に設定されている場合、H.323 ゲートウェイは SDN をサポートします。Cisco Unified CallManager は、ベアラ機能を Speech for the ACCUNET サービスとしてコーディングします。
ルート パターンの使用方法
ルート パターンは、Cisco Access Gateway に直接割り当てるか、柔軟性を高めるためにルート リストに割り当てることができます。たとえば、図17-2 では、Cisco Access Digital Gateway 1 が、一致するルート パターンがダイヤルされるときに、PSTN に発信コールをルーティングするための第 1 選択肢として指定されています。
ヒント ゲートウェイにルート パターンの指定がない場合は、PSTN または PBX にコールを発信することはできません。ゲートウェイ上の個々のポートにルート パターンを割り当てるには、ルート リストとルート グループをそのポートに割り当てる必要があります。
図17-2 では、Cisco Digital Gateway に対してルート パターンを使用する場合の効果を示しています。この例では、ルート パターンがルート リストに割り当てられ、そのルート リストは 1 つのルート グループに関連付けられています。ルート グループは、アベイラビリティに応じて選択されるデバイスのリストをサポートします。
システムが最初にコールをルート リストのメンバーに提供する場合、Cisco Unified CallManager は「帯域幅の範囲外です」、「ユーザがビジーです」、および「未割り当ての番号です」以外のすべての原因コードで再ルーティングします。「帯域幅の範囲外です」、「ユーザがビジーです」、および「未割り当ての番号です」の原因コードで再ルーティングするかどうかは、Cisco CallManager サービスの関連するサービス パラメータの値によって決まります。クラスタ全体のパラメータ（ルート プラン）グループには、Stop Routing on Out of Bandwidth Flag、Stop Routing on User Busy Flag、および Stop Routing on Unallocated Number Flag というサービス パラメータが含まれています。各サービス パラメータを［True］または［False］に設定できます。
ルート リストがトランクにロックされた後、再ルーティングは行われません。エンドポイントのメディア接続時間および Stop Routing サービス パラメータによって、ルート リストがいつ次のルート グループのハンティングを停止するかが決まります。メディア ネゴシエーションが開始されると、ルート リストまたはハント リストは再ルーティング機能を失います。
ルート リスト経由でリモート サイトにルーティングされているコールが解放され、Q.931 原因コードが Cisco Unified CallManager に送信された場合のルーティング動作は、Cisco CallManager サービスの Stop Routing on Q.931 Disconnect Cause Code サービス パラメータによって決まります。メッセージ内で検出された原因コードと、このパラメータで指定されている原因コードが一致した場合、ローカル Cisco Unified CallManager はコールのルーティングを停止します（そのコールは、ルート リスト内の次のデバイスには送信されません）。
（注） ゲートウェイにルート パターンが関連付けられている場合に、そのゲートウェイのリソースがすべて使用されていると、コールのルーティングは行われません。
図17-2 Cisco Digital Gateway 用のルート プランの要約図
図17-3 では、Cisco Analog Gateway に対してルート パターンを使用する場合の効果を示しています。この例では、ルート パターンがルート リストに割り当てられ、そのルート リストは 2 つのルート グループに関連付けられています。ルート グループ 1 は、ゲートウェイ 1 上のポート 1 ～ 8 に関連付けられ、これらのポートは、すべてのコールを中継キャリア 1（IXC 1）にルーティングします。ルート グループ 1 は、ゲートウェイ 2 上のポート 1 ～ 4 にも関連付けられています。ルート グループ 2 は、ゲートウェイ 2 上のポート 5 ～ 8、およびゲートウェイ 3 上のすべてのポートに関連付けられています。
各ルート グループは、グループ間のアベイラビリティに応じて選択されるデバイスをサポートしています。ルート グループ 1 では、第 1 選択肢のゲートウェイ上のポート 1 ～ 8 がビジーまたは使用停止中である場合、コールは、第 2 選択肢のゲートウェイ上のポート 1 ～ 4 にルーティングされます。ルート グループ 1 のすべてのルートが使用できない場合、コールはルート グループ 2 にルーティングされます。ルート グループ 2 では、第 1 選択肢のゲートウェイ上のポート 5 ～ 8 がビジーまたは使用停止中である場合、コールは、第 2 選択肢のゲートウェイ上のポート 1 ～ 8 にルーティングされます。どちらのルート グループのゲートウェイ上のポートも使用できない場合、コールは全トランク ビジー トーンにルーティングされます。
図17-3 Cisco Analog Access Gateway 用のルート プランの要約図
回線グループ
回線グループには 1 つまたは複数の電話番号が含まれます。Top Down、Circular、Longest Idle Time、Broadcast などの分散アルゴリズムが回線グループに関連付けられます。また、回線グループには［RNA予約タイムアウト（RNA Reversion Timeout）］も関連付けられています。
• アイドル状態の メンバーとは、どのコールも扱っていないメンバーである。
• 使用可能な メンバーとは、アクティブ コールを扱っているが、新しいコール（複数も可）を受け入れることができるメンバーである。
• 使用中の メンバーは、どのコールも受け入れることができない。
回線グループの設定については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「回線グループの設定」を参照してください。
（注） リリース 4.1 より前の Cisco Unified CallManager では、回線グループがルート/ハント リストに属することができました。Cisco Unified CallManager のリリース 4.1 からは、回線グループはハント リストに属し、ルート グループはルート リストに属します。
Cisco Unified CallManager のリリース 4.1 からは、電話番号が複数の回線グループに属することができます。
ハント リスト
ハント リストは、回線グループの順序付きグループで構成されます。回線グループは、複数のハント リストに属することができます。ハント パイロットは、ハント リストに関連付けられます。ハント リストは、複数のハント パイロットに関連付けることができます。
ハント リストの設定については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント リストの設定」を参照してください。
（注） リリース 4.1 より前の Cisco Unified CallManager では、ハント リストとルート リストの設定を 1 つのウィンドウで行っていました。リリース 4.1 からは、ハント リストとルート リストを別々に設定します。
（注） Cisco Unified CallManager のリリース 4.0 では、回線グループとルート グループの両方をルート/ハント リストのメンバーにすることができました。Cisco Unified CallManager のリリース 4.1 では、既存のルート/ハント リストのメンバーとして回線グループが含まれる場合、Cisco Unified CallManager はそのルート/ハント リストをハント リストに移行します。
（注） TOD 設定は、回線がハント リストに含まれている場合に有効になります。この設定は、そのハント リスト内の回線ではなく、ハント パイロットにだけ適用されます。
ハント パイロット
ハント パイロットは番号のセットです。ハント パイロットは、ハンティングに使用されるルート パターンのリストで構成されます。ハント パイロットは、パーティション、番号計画、ルート フィルタ、およびハント転送の設定を指定できます。ハント パイロットは、ハント リストを指定する必要があります。
ハント パイロットの設定については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント パイロットの設定」を参照してください。
（注） リリース 4.1 より前の Cisco Unified CallManager では、ハント パイロットとルート パターンの設定を 1 つのウィンドウで行っていました。リリース 4.1 からは、ハント パイロットとルート パターンを別々に設定します。
（注） Cisco Unified CallManager のリリース 4.0 では、ルート リストとハント リストの両方がルート パターン/ハント パイロットに関連付けられていました。Cisco Unified CallManager のリリース 4.1 では、既存のルート パターン/ハント パイロットがハント リストに関連付けられている場合、Cisco Unified CallManager はそのルート パターン/ハント パイロットをハント パイロットに移行します。
（注） TOD 設定は、回線がハント リストに含まれている場合に有効になります。この設定は、そのハント リスト内の回線ではなく、ハント パイロットにだけ適用されます。
コール カバレッジ
Cisco Unified CallManager のリリース 4.1 で初めて実装されたコール カバレッジ機能には、Cisco Unified CallManager の次の機能が含まれています。
• コールの発信者が内部ユーザであるか外部ユーザであるかに基づいて、転送を別々に設定できる。「内部コールと外部コール」を参照してください。
• ハンティングは、個人転送をサポートしている。「個人プリファレンス」を参照してください。
• Cisco Unified CallManager 4.0 では、ルート パターンとハント パイロットが 1 つの機能にまとめられていた。Cisco Unified CallManager 4.1 以降のリリースでは、ルート パターンとハント パイロットが 2 つの異なる機能に分離されています。
ハンティングとコール転送
ハンティングの概念は、コール転送の概念とは異なります。ハンティングでは、Cisco Unified CallManager がコールを 1 つまたは複数の番号リストに送り届けることができます。このような各リストは、アルゴリズムの固定セットから選択されるハンティング順序を指定できます。コールがこれらのリストからハント パーティに送り届けられ、そのパーティが応答できないまたは使用中の場合、次のハント パーティに対してハンティングが再開されます（次のハント パーティは、現在のハント アルゴリズムによって異なります）。このように、ハンティングでは、試行されるパーティの Call Forward No Answer（CFNA; 無応答時転送）設定も、Call Forward Busy（CFB; 話中転送）設定も、Call Forward All（CFA; 不在転送）設定も無視されます。
コール転送では、着信側が応答できないか使用中で、かつハンティングが実行されない場合に、コールを送り届ける（ 転送 も リダイレクト も 送り届ける に相当する用語）方法について、詳細に制御できます。たとえば、回線の CFNA 設定がハント パイロット番号に設定されている場合、その回線へのコールが応答されないと、そのコールはハント パイロット番号に転送されるため、ハンティングが開始されます。
Cisco Unified CallManager のリリース 4.1 からは、ハンティングに失敗した場合（つまり、リスト内のハント番号をすべて試したかタイムアウトのため、どのハント パーティも応答せずにハンティングが終了した場合）、Cisco Unified CallManager はコールをリダイレクトする機能を提供します。この最終リダイレクションは、使用される場合、コール転送アクションで構成されます。したがって、［ハント パイロットの設定（Hunt Pilot Configuration）］ウィンドウには、［電話番号の設定（Directory Number Configuration）］ウィンドウに似たコール転送設定概念が含まれています。
コール ハンティングの例
ハンティングは転送とは異なりますが、多くの場合、ハンティングはハント パイロット番号に転送されるコールとして開始されます。コール カバレッジ機能は、ハンティングを拡張し、ハンティングが実行し尽くされたまたはタイムアウトになった後の最終転送を可能にします。
ハンティングを起動する一般的なコールは、次のフェーズで構成されます。
2. コールがハンティングに転送されます（たとえば、本来の着信側回線の Call Forward All（CFA; 不在転送）、無応答時転送（CFNA）、または話中転送（CFB）設定のため）。
3. コールは、各グループのプロビジョニングされたアルゴリズムに従い、プロビジョニングされたハント グループを介してハンティングを実行します。ハンティングは、成功するか（ハント パーティが応答した場合）、実行し尽くされるか（すべてのハント パーティが試行されたが、どのパーティも応答しなかった場合）、タイムアウトになります（すべてのパーティが試行される前に［最大ハント タイマー（Maximum Hunt Timer）］に指定されている時間になり、試行されたどのパーティも応答しなかった場合）。
この例では、ハンティングが成功しない場合を想定します。
4. 何らかの形で最終転送が設定されている場合、コールは次の宛先に転送されます。最終転送が設定されていない場合、コールは解放されます。
最大ハント タイマー（Maximum Hunt Timer）
［ハント パイロットの設定（Hunt Pilot Configuration）］ウィンドウの［最大ハント タイマー（Maximum Hunt Timer）］フィールドでは、管理者が、ハント リストを介したハンティングの時間を制限する値（秒単位）を入力できます。指定した時間を経過してもハンティングが成功しなかった場合、コールはボイス メッセージ システム、特定の電話番号、または個人処理（設定されている場合）に転送されるか、解放されます。
［最大ハント タイマー（Maximum Hunt Timer）］の詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント パイロットの設定」のフィールドの説明を参照してください。
内部コールと外部コール
コールの発信者が内部ユーザであるか外部ユーザであるかに基づいて、転送を別々に設定できます。この区別は、Call Forward Busy（CFB; 話中転送）、Call Forward No Answer（CFNA; 無応答時転送）、および Call Forward No Coverage（カバレッジなし時転送）の場合に適用されます。
個人プリファレンス
ハンティングは、実行し尽くされたかタイムアウトになったときに、ボイス メッセージ システム、特定の電話番号、または個人処理（本来の着信側に基づく）に最終的な転送処理を提供する機能をサポートしています。コールが内部コールであるか外部コールであるかに基づいて、別々の最終転送処理を提供する機能も用意されています。ハンティングは、ハント パイロット番号ごとに別々に設定できる［最大ハント タイマー（Maximum Hunt Timer）］をサポートしています。
［ハント パイロットの設定（Hunt Pilot Configuration）］の設定では、［個人の初期設定を使用（Use Personal Preferences）］フィールドと［着信先（Destination）］フィールドを使用して、コールをハント パイロットに転送した本来の着信側番号の Call Forward No Coverage（CFNC; カバレッジなし時転送）設定を使用可能にすることができます。『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント パイロットの設定値」の項を参照してください。
Closest Match ルーティング
Closest Match ルーティングとは、電話番号に最も近いルート パターンを使用してコールをルーティングするプロセスです。Cisco Unified CallManager で複数のルート パターンと一致する電話番号が検出された場合、Closest Match ルーティングを使用して、その番号に最も近いルート パターンを判別し、そのルート パターンを使用してコールを送信します。
2 つの設定済みルート パターンが、別々のパーティションで同一番号のアドレスと完全に一致する場合、Cisco Unified CallManager は、そのパーティションがコーリング サーチ スペース内でリストされている順番に基づいて、ルート パターンを選択します（Cisco Unified CallManager は、コーリング サーチ スペース内の先頭に表示されるパーティションから、ルート パターンを選択します）。
2 つの設定済みルート パターンが、1 つのパーティションで同一番号のアドレスと完全に一致する場合、Cisco Unified CallManager は任意にどちらかのパーティションを選択します。このような完全一致が生じる状況は例外であるため、その理由を説明します。
複数のルート パターンが 1 つの番号に一致することがあります。たとえば、番号 8912 は、8912、89XX、および 8XXX のどのルート パターンとも一致します。
この例では、ルート パターン 8912 は 1 つのアドレスと完全に一致します。ルート パターン 89XX は、8912、およびその他の 99 個のアドレスと一致します。また、ルート パターン 8XXX は、8912、およびその他の 999 個のアドレスと一致します。
ユーザが 8913 をダイヤルする場合、そのコールのルーティング方法はさまざまです。直前の例を使用すると、このアドレスは、ルーティング パターン 89XX および 8XXX だけと一致します。89XX が一致するアドレスの範囲は、8XXX より狭いので、Cisco Unified CallManager は、ルーティング パターン 89XX に割り当てられるデバイスにそのコールを送信します。
ルート パターンでの @ ワイルドカードの使用方法
ルート パターン内で @ ワイルドカード文字を使用すると、単一ルート パターンをすべての NANP 番号と一致させることができますが、ほかにも次の考慮事項があります。
数字 92578912 は、ルート パターン 9.@ と 9.XXXXXXX の両方と一致します。どちらのルート パターンも、同じようにアドレスと一致するように見える場合であっても、実際には、9.@ ルート パターンが Closest Match になります。@ ワイルドカード文字では、さまざまなルート パターンが含まれます。そのルート パターンの中の 1 つが［2-9］［02-9］XXXXX です。番号 2578912 は、XXXXXXX よりも［2-9］［02-9］XXXXX に近いので、9.@ ルート パターンが、ルーティング用の Closest Match になります。
ルート パターンを設定する際には、次のことを考慮してください。
• ルーティング パターンで @ が使用されている場合、# は、国際電話のダイヤル終了文字として自動的に認識されます。@ を使用しないルーティング パターンの場合、ダイヤル終了を知らせる # 文字を使用できるようにするには、ルーティング パターンに # を組み込む必要があります。
• ルート パターンにアットマーク（@）が含まれている場合、［番号の削除（Discard Digits）］フィールドには DDI を指定します。
「特殊文字と設定値」には、DDI の一覧、および電話番号に各 DDI を適用した結果についての説明があります。
discard digits instruction（DDI; 数字破棄命令）は、電話番号の一部を削除してから、その番号を隣接システムに渡します。数字列の一部を削除する必要があるのは、たとえば、PSTN にコールをルート指定するのに外部アクセス コードが必要であるにもかかわらず、PSTN スイッチがそのアクセス コードを要求しない場合です。
（注） @ を使用しないパターンに対して使用できる DDI は、<None>、NoDigits、および PreDot だけです。
スタティック番号分析
リリース 4.0 より前の Cisco Unified CallManager では、転送が設定されていない登録解除されたデバイスは、digit analysis（DA; 番号分析）テーブルから削除され、ダイナミック番号分析を必要としました。リリース 4.0 より前では、電話機が登録解除された場合、コール処理でコールを Calling Search Space（CSS; コーリング サーチ スペース）リスト内の次の Closest Match に渡すことができました。リリース 4.0 ではスタティック DA が導入され、電話機が登録されているかどうかに関わらず、デバイスが DA テーブルに残り、その電話番号がコールを代行受信します。
• 管理者は、Cisco Unified CallManager Assistant がフェールオーバーに変換パターンを使用しないことに注意する必要があります。その代わり、管理者は、すべての Unified CM Assistant 障害ルート ポイントの変換パターンにあったデータで Call Forward No Answer（CFNA; 無応答時転送）を設定し、これらのルート ポイントを削除する必要があります。
Cisco Unified CallManager のリリース 4.0 からは、番号分析プロセスが、システムの初期化中に、データベースに設定されているパターンでスタティック番号分析エンジンを構築します。この番号分析エンジンは、Cisco Unified CallManager クラスタ内のパターンの伝搬を減らし、Cisco Unified CallManager をさらにスケーラブルにします。
以前のリリースでは、個々のデバイス制御プロセスがデータベースからパターン情報を読み取り、パターンを番号分析プロセスに動的に登録して、番号分析エンジンを構築していました。各パターンは、番号分析エンジン内に制御プロセス ID へのマッピングを持っていました。パターンの制御プロセス ID は、関連付けられているデバイスがリセットされるか、Cisco Unified CallManager サーバが再起動すると、動的に変更されました。制御プロセス ID が変更されると、番号分析エンジンを動的に変更して、その内容を他の Cisco Unified CallManager サーバに伝搬する必要がありました。コール処理中、番号分析エンジンは、一致したパターンの制御プロセス ID を戻しました。
Cisco Unified CallManager のリリース 4.0 からは、Cisco Unified CallManager の初期化中に、番号分析プロセスがデータベースから直接パターン情報を読み取り、スタティック番号分析エンジンを構築します。スタティック番号分析エンジンでは、各パターンが、コールできるエンドポイント名へのマッピングを持っています。そのマッピングは、データベース内のパターンの NumPlanPkID で、Cisco Unified CallManager に設定されているパターンへの一意な識別子です。スタティック番号分析エンジンは、パターンの制御プロセス ID を保持しなくなりました。
スタティック番号分析は、デバイス マネージャへの変更と統合され、既存のすべての機能をサポートします。デバイス マネージャには、NumPlanPkID がパターンの制御プロセス ID への 1 対 1 のマッピングを示すテーブルが含まれています。番号分析は、コールを処理するときに、デバイス マネージャに問い合せて、一致するパターンの制御プロセス ID を取得します。
Cisco Unified CallManager には、コール パーク、コール転送、ミートミー会議、デバイス、変換、コール ピックアップ グループ、ルート、およびメッセージ受信というパターン タイプがあります。デバイス、変換、およびルートというパターン タイプは、スタティック パターンを示します。番号分析プロセスは、Cisco Unified CallManager の初期化中に、これらのパターンを直接読み取り、スタティック番号分析エンジンに挿入します。他のパターン タイプ（コール パーク、コール転送、ミートミー会議、コール ピックアップ グループ、およびメッセージ受信）は、代行受信パターンで、ダイナミック パターンのままです。個々の制御プロセスは、データベースからパターン情報を読み取ります。次に、登録メッセージを介して、そのパターン情報をスタティック番号分析エンジンに挿入するよう、番号分析プロセスに対して要求します。
データベース内でレコードが変更されるまで、すべてのスタティック パターンは変更されないままです。データベース変更通知がクラスタ内のサーバにブロードキャストされるため、スタティック パターンは伝搬の必要がありません。ダイナミック パターンは、依然として既存の伝搬および更新メカニズムを使用して、スタティック番号分析エンジンを更新します。
パターン タイプに関係なく、スタティック番号分析エンジン内の各スタティック パターンは、データベースの NumPlan テーブル内の PkID へのマッピングを持っています。デバイスがパターンをデバイス マネージャに登録すると、デバイス マネージャ内で同じ PkID が保存されて制御プロセス ID にマッピングされます。コールの処理中にスタティック番号分析エンジン内で一致するパターンが見つかると、番号分析とデバイス マネージャの間の新しいインターフェイスが制御プロセス ID を取得します。
現在の Cisco Unified CallManager リリースでは、変更通知が失われる可能性があります。この損失により、他のデバイスが、Cisco Unified CallManager に登録されているデバイスに到達できなくなることがあります。この問題のトラブルシューティングについて、次に説明します。
この問題は、あるパーティションに属するデバイスに割り当てられた DN が、他のデバイスのコーリング サーチ スペースに含まれていない場合に、最も多く発生します。他のデバイスのコーリング サーチ スペースに、その DN のパーティションが含まれている場合は、別の原因が考えられます。たとえば、DN がデバイスのためだけに変更され、データベースから Cisco Unified CallManager への変更通知が失われた場合などが考えられます。Cisco Unified CallManager リリース 4.0 以降では、デバイスをリセットしてもこの問題を解決できない場合があります。
この問題を解決するには、DN を削除してシステムに再度追加します。［電話番号の設定（Directory Number Configuration）］ウィンドウおよび［ルート プラン レポート（Route Plan Report）］ウィンドウでデバイスから DN を削除します。DN を削除した後、パーティション、パターン、および他の情報を同様に設定して DN を再度追加します。新しい DN を Cisco Unified CallManager に再度追加すると、問題が解決されます。
同様の問題が存在する場合は、ルート パターンおよび変換パターンに同じ対処法を適用できます。
ヒント パターンを削除する前に、すべての設定を書き留めておいてください。
スタティック番号分析は、いくつかのアプリケーションの設定を使用不可にします。そのアプリケーションとは、同じコーリング サーチ スペース内の重複パターンのプロビジョニングに依存するアプリケーションです。たとえば、CTI アプリケーションがパーティション A 内のパターン 5000 であり、特定の電話機がパーティション B 内のパターン 5000 であるとします。以前のリリースでは、CTI ルート ポイントがダウンしている場合、電話機の呼び出し音が鳴ります。ただし、スタティック番号分析では、発信者にビジー トーンが聞こえます。この制限は、アプリケーションの障害が処理されないことを意味します。
管理者は、通常、Call Forward No Answer（無応答時転送）および Call Forward On Failure（CTI 障害時転送）を使用して、アプリケーションの障害を処理します。ただし、CTI ルート ポイントのパターンが 5XXX である場合は、5XXX という転送先を設定できません。この制限を解決するために、コール転送の宛先に X 文字を設定できるようになりました。
次の例では、Cisco Unified CallManager Assistant アプリケーションに対する、リリース 4.0 より前の（ダイナミック番号分析を使用した）番号分析機能と、リリース 4.0 以降の（スタティック番号分析を使用した）番号分析機能を示しています。
リリース 4.0 より前の番号分析を使用した IPMA の例
CTI route point（RP; ルート ポイント）が稼働している場合に、1000/IPMA:EveryOne が 1001 をコールするとします。コールは、CTI ルート ポイント IPMA/1XXX を使用してルーティングされます。
CTI ルート ポイントがダウンしている場合に、1000/IPMA:EveryOne が 1001 をコールするとします。コールは、変換パターン Everyone/1xxx, を経由し、変換後に Manager/1001 に到達して、IPMA アプリケーションの目的を果たします。
リリース 4.0 以降のスタティック番号分析を使用した Cisco Unified CallManager Assistant の例
リリース 4.0 以降で同じ設定を想定する場合、CTI ルート ポイントに障害が発生した場合の処理のために、CTI ルート ポイントに対して、CFNA マスクとして 1xxx を、CFNA コーリング サーチ スペースとして CSS-E を設定する必要があります。
スタティック番号分析が使用される場合は、次の処理が行われます。
• CTI RP が稼働している場合に、1000/IPMA:EveryOne が 1001 をコールするとします。コールは、CTI ルート ポイント IPMA/1XXX を介してルーティングされます（ルーティングは以前のバージョンから変わりません）。
• CTI ルート ポイントダウンしている場合に、1000/IPMA:EveryOne が 1001 をコールするとします。コールは、CTI ルート ポイントに送信され、その CFNA がトリガーされます。転送機能により、コールが変換パターン Everyone/1xxx を介してルーティングされ、変換後に Manager/1001 に到達します。
CTI ルート ポイントに CFNA を設定しないと、変換パターンが一致せず、Cisco Unified CallManager Assistant アプリケーションが失敗します。
特殊文字と設定値
Cisco Unified CallManager の管理ページを使用すると、特殊文字と設定値を使用して次のタスクを実行することができます。
• 1 つのルート パターンまたはハント パイロットを番号の範囲と一致させる
• 発信コール用のダイヤル数字列、つまり着信側番号を操作する
特殊文字と設定値の使用方法の詳細については、次のトピックを参照してください。
• 「ルート パターンとハント パイロット内のワイルドカードと特殊文字」
• 「数字破棄命令」
ルート パターンとハント パイロット内のワイルドカードと特殊文字
ルート パターンおよびハント パイロットでワイルドカードおよび特殊文字を使用すると、単一ルート パターンまたはハント パイロットをある範囲の番号（アドレス）と一致させることができます。これらのワイルドカードと特殊文字は、Cisco Unified CallManager が隣接システムに番号を送信する前にその番号を操作できるようにする命令の作成にも使用します。
表17-3 では、Cisco Unified CallManager がサポートするワイルドカードと特殊文字について説明します。
表17-4 では、ルート パターンまたはハント パイロットを必要とする Cisco Unified CallManager の管理ページのフィールドを一覧表示し、各フィールドの有効な入力内容を示します。
|
|
|
|---|---|
数字破棄命令
discard digits instruction（DDI; 数字破棄命令）は、電話番号の一部を削除してから、その番号を隣接システムに渡します。DDI が数字列の一部を削除する必要があるのは、たとえば、PSTN にコールをルート指定するのに外部アクセス コードが必要であるにもかかわらず、PSTN スイッチがそのアクセス コードを要求しない場合です。
表17-5 では、DDI をリストし、ダイヤル番号に各 DDI を適用した結果について説明します。
発信側および着信側の変換
Cisco Unified CallManager の管理ページでは、Cisco Unified CallManager が各コール設定メッセージで送信する発信側番号と着信側番号を操作することができます。
発信側番号の変換設定値
発信側変換設定値では、発信コール用の発信側番号を操作することができます。Cisco Unified CallManager は、Calling Line Identification（CLID）に発信側の番号を使用します。発信コール時に、CLID は、各構内交換機（PBX）、セントラル オフィス（CO）、および中継キャリア（IXC）に、コールの進行状況として渡されます。コールが着信側に配信されたときに、着信側で CLID を受け取ります。
ルート リストで使用される発信側変換設定は、ルート リストを構成する個々のルート グループに適用されます。ルート リスト内のルート グループに割り当てられる発信側変換設定値は、そのルート リストに関連したルート パターンに割り当てられている発信側変換設定値をすべて上書きします。
ルート グループの設定では、次の発信側変換設定値を指定することができます。
• ［発呼側の外線電話番号マスクを使用（Use Calling Party's External Phone Number Mask）］
• ［発呼側変換マスク（Calling Party Transform Mask）］
• ［プレフィックス番号（Prefix Digits、発信コール）］
表17-6 では、発信側番号変換の指定に使用するフィールド、オプション、および値について説明します。
着信側番号の変換設定値
着信側変換設定値では、発信コール用にダイヤルする数字、つまり着信側の番号を操作することができます。着信側の番号を操作する例としては、プレフィックス番号の付加または削除（発信コール）、7 桁の番号としてダイヤルされるコールへのエリア コードの付加、4 桁または 5 桁の内線番号としてダイヤルされるオフィス間コールへのエリア コードとオフィス コードの付加、および等価アクセス コールに対する通信事業者アクセス コードの抑止があります。
ルート リストで使用される着信側変換設定は、ルート リストを構成する個々のルート グループに適用されます。ルート リスト内のルート グループに割り当てられる着信側変換設定値は、そのルート リストに関連したルート パターンまたは変換パターンに割り当てられている着信側変換設定値をすべて上書きします。
ルート グループ、ルート パターン、および変換パターンの設定で、次の着信側変換設定値を指定することができます。
• ［着信側変換マスク（Called Party Transform Mask）］
• ［プレフィックス番号（Prefix Digits、発信コール）］
表17-7 では、着信側番号変換の指定に使用するフィールド、オプション、および値について説明します。
|
|
|
|---|---|
|
|
|
このフィールドには、数字破棄命令を制御する破棄パターンのリストが含まれています。たとえば、ユーザが PSTN（公衆電話交換網）にコールするのに、9 をダイヤルする必要があるシステムでは、PreDot 破棄パターンによって、ダイヤル数字列からその 9 が削除されます。詳細については、「Closest Match ルーティング」を参照してください。
（注） デフォルト設定である［<None>］以外の設定は、ルート パターンの設定を上書きします。［<None>］の設定は、「数字を破棄しない」ことを意味します。 |
|
このフィールドは、このルート グループを介してルーティングされるすべてのコールに対して、着信側変換マスクを指定します。このフィールドの有効値は、0 ～ 9 の数字、ワイルドカード文字 X、および文字 * と # です。また、このフィールドをブランクのままにすることもできます。このフィールドがブランクの場合、変換は行われません。つまり、Cisco Unified CallManager は、ダイヤルされたとおりに数字を送信します。 |
|
このフィールドには、このルート グループを介してルーティングされるすべてのコールについて、着信側番号に付加されるプレフィックス番号、または 1 組の［プレフィックス番号（Prefix Digits、発信コール）］が含まれます。このフィールドの有効値は、0 ～ 9 の数字、文字 * と #、およびブランクです。［プレフィックス番号（Prefix Digits、発信コール）］には、ルート パターンで最長 50 桁、DN で最長 24 桁を指定できます。 |
|
発信者 ID および制限
Cisco Unified CallManager では次のタイプの発信者 ID 情報を提供します。
• Calling Line Identification（CLID; 発信側回線 ID）：着信側のディスプレイに発信側の内線番号または電話番号を表示する。
• Calling Name Identification（CNID; 発信名前表示）：着信側のディスプレイに発信側の名前を表示する。
• 接続回線 ID 表示：発信側のディスプレイに接続先の電話番号を表示する。
• 接続名表示：発信側のディスプレイに接続先の名前を表示する。
Cisco CallManger には、発信側と着信側の両方に対し、回線情報および名前情報の表示を許可および制限するための柔軟な設定オプションがあります。
発信者 ID の設定方法の詳細については、次のトピックを参照してください。
発信側情報の表示設定と制限設定
発信側表示情報によって、Cisco Unified CallManager が発信コール用の設定メッセージと共に送信する電話番号および名前情報を表示するかどうかを制御します。Cisco Unified CallManager では次のフィールドを使用してこれらの補助サービスを提供します。
• ［発呼側回線IDの表示（Calling Line ID Presentation）］フィールド：calling line identification presentation（CLIP）または calling line identification restriction（CLIR）
• ［発呼名プレゼンテーション（Calling Name Presentation）］フィールド：calling name presentation（CNIP）または calling name restriction（CNIR）
［ゲートウェイの設定（Gateway Configuration）］ウィンドウの［発呼側のプレゼンテーション（Calling Party Presentation）］フィールドを使用して、ゲートウェイ上の発信コールすべてに CLID を表示するかどうかを制御することができます。コールごとに CLID の表示を制御するには、［ルート パターンの設定（Route Pattern Configuration）］ウィンドウまたは［変換パターンの設定（Translation Pattern Configuration）］ウィンドウの［発呼側回線IDの表示（Calling Line ID Presentation）］フィールドを使用します。
（注） コール表示制限を設定するには、［発呼側回線 ID の表示（Calling Line ID Presentation）］と［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］を［プレゼンテーション インジケータを無視 （Ignore Presentation Indicators、内線コールのみ）］デバイスレベル パラメータと組み合せて設定してください。同時に、これらの設定では、各コールの発信側と接続先の両方またはいずれか一方の回線表示情報を選択的に表示またはブロックできます。［プレゼンテーション インジケータを無視（Ignore Presentation Indicators、内線コールのみ）］フィールドの詳細については、『Cisco Unified CallManager アドミニストレーション ガイド』の「デバイス プロファイルの設定」の章および「Cisco Unified IP Phone の設定」の章を参照してください。コール表示制限の詳細については、『Cisco Unified CallManager 機能およびサービス ガイド』の「コール表示制限について」の章を参照してください。
次の例で、発信側回線 ID 表示の機能について説明します。ユーザがコールを行うと、Cisco Unified CallManager はダイヤルされた番号が変換パターンと一致するかどうかをチェックします。Cisco Unified CallManager が一致を見つけて、表示インジケータに変換パターン［発呼側回線IDの表示（Calling Line ID Presentation）］フィールドの値を設定します。この例では［Restricted］に指定されています。次に、Cisco Unified CallManager は、ダイヤル番号に設定されたルート パターン上で一致をチェックして見つけます。Cisco Unified CallManager は［発呼側回線IDの表示（Calling Line ID Presentation）］フィールドをチェックして、この値に［Default］が指定されていることを確認します。［Default］が設定されている場合、前の設定は変更されないため、表示インジケータは［Restricted］のままになります。
ゲートウェイの［発呼側のプレゼンテーション（Calling Party Presentation）］フィールドが最後に確認されます。この例で、値は［Allowed］に指定されており、前の［発呼側回線IDの表示（Calling Line ID Presentation）］インジケータを上書きして発信側番号が着信側の電話機に表示されるようにします。したがって、［発呼側回線IDの表示（Calling Line ID Presentation）］フィールドのインジケータは、発信側でコールを開始したときの［Restricted］から変更されて、Cisco Unified CallManager がコール設定メッセージをエンドポイント デバイスへ送信するまでに［Allowed］となります。
［ルート パターンの設定（Route Pattern Configuration）］ページまたは［変換パターンの設定（Translation Pattern Configuration）］ページを使用すると、発信コールおよび着信コールについて、回線と名前の表示または制限をコールごとに設定することができます。
ゲートウェイについては、発信コール用に発信側回線 ID 表示だけを設定できます。着信コールに対しては、Cisco Unified CallManager はゲートウェイの［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］フィールドを使用して、接続先の番号を発信側の電話機に表示するか、または制限するかを指定します。ゲートウェイ設定が適用されるのはこれら 2 つの場合だけで、この設定はその他の設定をすべて上書きします。ゲートウェイについては、発信側および接続先の回線表示だけを設定できます。ゲートウェイ上の名前表示を制御する設定はありません。
コールを処理するデバイス コントロール プロトコルのタイプによって、発信者の名前および番号情報が制限されます。プロトコルと、サポートされている発信者の名前および番号情報のリストについては、表17-10 を参照してください。
（注） 非 QSIG トランクに対する名前表示を制御するには、［ゲートウェイの設定（Gateway Configuration）］ウィンドウで［IE 配信を表示（Display IE Delivery）］フィールドまたは［ファシリティ IE でのコール名を送る（Send Calling Name In Facility IE）］フィールドを使用可能にする必要があります。
表17-8 では、発信側表示の指定に使用するフィールド、オプション、および値について説明します。
|
|
|
|---|---|
［発呼側回線IDの表示（Calling Line ID Presentation）］（発信コール）または［発呼側のプレゼンテーション（Calling Party Presentation）］ |
このフィールドは、発信側電話番号を着信側の番号表示画面に表示するかどうかを決定します。［発呼側回線IDの表示（Calling Line ID Presentation）］フィールドは、［ゲートウェイの設定（Gateway Configuration）］ウィンドウ、［ルート パターンの設定（Route Pattern Configuration）］ウィンドウ、および［変換パターンの設定（Translation Pattern Configuration）］ウィンドウで使用されます。 • • • |
このフィールドは、発信側の名前を着信側の番号表示に表示するかどうかを決定します。［発呼名プレゼンテーション（Calling Name Presentation）］フィールドは［ルート パターンの設定（Route Pattern Configuration）］ウィンドウおよび［変換パターンの設定（Translation Pattern Configuration）］ウィンドウで使用されます。 • • •
（注） ゲートウェイには発信側名前表示に関する設定がありません。 |
|
着信コールが変換パターンまたはルート パターンを経由し、［発呼側回線IDの表示（Calling Line ID Presentation）］が［Allowed］または［Restricted］に設定されている場合、発信側の回線表示は変換パターンまたはルート パターンの設定で変更されます。Cisco Unified CallManager システムに到達したコールが PBX または PSTN へ送信される場合は、発信コールの規則が適用されます（「発信側情報の表示設定と制限設定」を参照）。
（注） ゲートウェイの［発呼側のプレゼンテーション（Calling Party Presentation）］設定は発信コールだけを制御します。 |
|
着信コールが変換パターンまたはルート パターンを経由し、［発呼名プレゼンテーション（Calling Name Presentation）］が［Allowed］または［Restricted］に設定されている場合、発信側の名前表示は変換パターンまたはルート パターンの設定で変更されます。Cisco Unified CallManager システムに到達したコールが PBX または PSTN へ送信される場合は、発信コールの規則が適用されます（「発信側情報の表示設定と制限設定」を参照）。
（注） ゲートウェイには名前情報を制御する設定がありません。 |
接続先情報の表示設定と制限設定
接続先表示情報によって、Cisco Unified CallManager が着信コールと共に受信する電話番号および名前情報を表示するかどうかを制御します。Cisco Unified CallManager では次のフィールドを使用してこれらの補助サービスを提供します。
• ［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］フィールド：connected line identification presentation（COLP）または connected line identification restriction（COLR）
• ［接続名プレゼンテーション（Connected Name Presentation）］フィールド：connected name presentation（CONP）または calling name restriction（CONR）
接続先設定により、接続先の電話番号および名前を発信側電話機に表示することを許可または制限することができます。［変換パターンの設定（Translation Pattern Configuration）］ウィンドウおよび［ルート パターンの設定（Route Pattern Configuration）］ウィンドウにこれら 2 つの設定が用意されています。コールが Cisco Unified CallManager および終端側の電話機に接続された後、発信側は接続先の名前情報を受信します。
次の例で接続先回線 ID の機能について説明します。Cisco Unified CallManager は着信コールを受信すると、その着信番号に変換パターンが設定されているかどうかを確認します。Cisco Unified CallManager は［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］フィールドの値を使用します。この例では［Restricted］に指定されています。次に、ルート パターンが着信コール用に設定されている場合は、［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］フィールドの値を確認します。この例で値は［Default］です。したがって、インジケータは［Restricted］のままになり、接続先の番号は発信側電話機に表示されません。
着信コールに対してだけ、ゲートウェイの［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］フィールド値を最後に確認します。この例では［Allowed］に設定されています。ゲートウェイ設定は、接続先の番号を発信側電話機に表示できるかどうかを指定します。この場合、Cisco Unified CallManager は CONNECT メッセージ内で［Allowed］を送信して、発信者の番号表示画面に接続先回線を表示できるようにします。
［ルート パターンの設定（Route Pattern Configuration）］ウィンドウまたは［変換パターンの設定（Translation Pattern Configuration）］ウィンドウを使用すると、発信コールおよび着信コールについて、接続先回線および名前の表示または制限をコールごとに設定することができます。
ゲートウェイ上の着信コールに対しては、［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］フィールドを使用して、接続先の番号を発信側電話機に表示するか、または制限するかを指定します。ゲートウェイ設定は回線表示設定だけに適用され、その他の設定をすべて上書きします。
（注） ゲートウェイについては、発信側および接続先の回線表示オプションだけを設定できます。ゲートウェイでの名前表示に関する設定はありません。
表17-9 では、接続先表示の指定に使用するフィールド、オプション、および値について説明します。
|
|
|
|---|---|
［ルート パターンの設定（Route Pattern Configuration）］ウィンドウおよび［変換パターンの設定（Translation Pattern Configuration）］ウィンドウで、このフィールドは発信側の番号表示に接続先の番号を表示するかどうかを決定します。 • • •
（注） この設定は内部コールと QSIG 接続でのコールだけに適用されます。 |
|
［接続名プレゼンテーション（Connected Name Presentation）］（CONP/CONR）（発信コール） |
このフィールドは、接続先の名前を発信側の番号表示に表示するかどうかを決定します。［接続名プレゼンテーション（Connected Name Presentation）］フィールドは［ルート パターンの設定（Route Pattern Configuration）］ウィンドウおよび［変換パターンの設定（Translation Pattern Configuration）］ウィンドウで使用されます。 • • • |
着信コールが変換パターンまたはルート パターンを経由し、［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］が［Allowed］または［Restricted］に設定されている場合、接続先の回線表示インジケータは変換パターンまたはルート パターンの設定で変更されます。
（注） ゲートウェイの［接続回線 ID プレゼンテーション（Connected Line ID Presentation）］設定は、接続先の番号を発信側の電話機に表示できるかどうかを決定します。 Cisco Unified CallManager システムに到達したコールが PBX または PSTN へ送信される場合は、発信コールの規則が適用されます（「接続先情報の表示設定と制限設定」を参照）。 |
|
着信コールが変換パターンまたはルート パターンを経由し、［接続名プレゼンテーション（Connected Name Presentation）］が［Allowed］または［Restricted］に設定されている場合、接続先の名前表示は変換パターンまたはルート パターンの設定で変更されます。Cisco Unified CallManager システムに到達したコールが PBX または PSTN へ送信される場合は、発信コールの規則が適用されます（「接続先情報の表示設定と制限設定」を参照）。
（注） ゲートウェイには名前情報を制御する設定がありません。 |
Cisco Unified CallManager のデバイス コントロール プロトコルによる発信者 ID サポート
Cisco Unified CallManager では、コールを処理するデバイス コントロール プロトコルに基づいて、発信者の名前および番号を表示します。すべてのデバイス プロトコルがプロトコル メッセージで発信者番号および名前の情報を提供するわけではありません。表17-10 は、発信者 ID サービスをサポートするプロトコルをまとめたものです。
|
|
|
|
|
|
|---|---|---|---|---|
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
ルート プラン レポート
ルート プラン レポートには、システム内のすべての未割り当て電話番号（DN）、コール パーク（転送先保留）番号、コール ピックアップ番号、会議番号（ミートミー番号）、電話番号、ルート パターン、変換パターン、ボイスメール ポート、メッセージ受信のインジケータ、およびコンソール番号のリストが含まれています。
ルート プラン レポートを使用すると、ルート パターン、パーティション、ルート グループ、ルート リスト、電話番号、コール パーク（転送先保留）番号、コール ピックアップ番号、会議番号（ミートミー番号）、またはゲートウェイを選択することにより、リストの一部または全部を表示したり、関連する設定ウィンドウに直接進んだりすることができます。
ルート プラン レポートを使用して、未割り当ての電話番号リストを取得し、必要に応じてこれらの番号を Cisco Unified CallManager データベースから削除することができます。
さらに、ルート プラン レポートを使用して .csv ファイルにレポート データを保管し、他の Bulk Administration Tools（BAT）などのアプリケーションにインポートすることもできます。この .csv ファイルには、電話機の電話番号（DN）、ルート パターン、変換パターンを含めて、詳しい情報が入っています。詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート プラン レポート」を参照してください。
参考情報
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「パーティションの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「コーリング サーチ スペースの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート グループの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート リストの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート パターンの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「回線グループの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント リストの設定」
• 『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ハント パイロットの設定」
• 『 Cisco Unified CallManager 機能およびサービス ガイド 』の「プレゼンス」
• Cisco Unified Communications ソリューション リファレンス ネットワーク デザイン（SRND）
フィードバック