この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、次の配置モデルについて、ダイヤル プランの設計上の考慮事項とガイドラインについて説明しています。
• 「すべての配置モデル用のダイヤル プラン ガイドライン」
次のダイヤル プラン ガイドラインは、すべての配置モデルに適用されます。
• 「コール制限」
• 「変換パターン」
ダイヤル プランが設計ガイドラインの許容範囲内にあることを確認するには、「ダイヤル プランの重み」の項も参照してください。
Cisco CallManager は、自動的に同じクラスタ内の宛先にコールをルーティングします。PSTN ゲートウェイ、H.323 ゲートキーパー、またはその他の Cisco CallManager クラスタなどの外部宛先の場合、Cisco CallManager で次のエレメントを使用して、明示的にルーティングを設定してください。
ルート パターンは、コールを外部エンティティにルーティングするために Cisco CallManager で設定された、数字とワイルドカードを組み合せた文字列(たとえば、9.[2-9]XXXXXX)です。
• @ ワイルドカードは、特殊なマクロ関数であり、North American Numbering Plan 全体を表す一連のパターンに拡張されます。たとえば、フィルタ処理されていない単一のルート パターン(たとえば、9.@)を設定すると、実際には、Cisco CallManager ダイヤル プラン設定に 166 個の個別ルート パターンが追加されます。
• 分散 PSTN ゲートウェイを備えた大規模な集中型コール処理配置の場合、@ ワイルドカードを使用するのではなく、ローカル PSTN アクセス用の明示ルート パターンを設定してください。この設定では、作成されるダイヤル プラン データベースのサイズが小さくなります。
• ルート フィルタは、@ ワイルドカードによって作成されるルート パターン数を減らすために、@ ルート パターン(通常、9.@)と一緒にのみ使用します。
• ルート フィルタと一緒に入力する論理式は、NOT-SELECTED フィールドを除いて、最大 1024 文字にすることができます。
• ルート フィルタ内の論理文節数が増えるにつれて、設定ページのリフレッシュ時間も増え、容認できないほど長くなる場合があります。
• 大規模な配置の場合、@ ワイルドカードとルート フィルタではなく、明示ルート パターンを使用してください。この方法を利用すると、管理とトラブルシューティングも容易になります。これは、Cisco CallManager で設定されているすべてのパターンが、Route Pattern コンフィギュレーション ページから簡単に参照できるからです。
• 国際間の宛先は、通常、任意の桁数を表す ! ワイルドカードを使用して設定されます。たとえば、北米では通常、国際コール用にルート パターン 9.011! が設定されています。
• ! ワイルドカードは、ダイヤルされる番号の長さが変化する国(たとえば、ドイツ)では配置にも使用されます。このような場合、Cisco CallManager は、ダイヤルがいつ完了するか分からないので、コールの送信前に 15 秒待機します。この遅延は、次の方法のいずれかで短縮できます。
–ダイヤルの終わりを指定する T302 タイマー(サービス パラメータ TimerT302_msec)の値を減らします。ただし、ユーザがダイヤルを終了する前のコールの早期送信を防止するために、4 秒以上に設定します。
–2 番目のルート パターンの後に # ワイルドカードを続けて設定し(たとえば、北米の場合 9.011!#)、ダイヤルの終わりを示すために # をダイヤルするようにユーザに指示します。この処置は、携帯電話で「送信」ボタンを押すことに相当します。
• 番号操作は、ルート パターンではなく、ルート グループのみで設定してください。
• ルート グループでの番号操作は、ルート パターンで行われた番号操作を完全に上書きします。
• ルート パターンで番号操作を設定する場合、コール詳細レコード(CDR)は、番号操作が行われた後のダイヤル番号を記録します。ルート グループだけで番号操作を設定する場合、CDR は、番号操作が行われる前の実際のダイヤル番号を記録します。
• 発信者番号識別の表示は、ゲートウェイで使用可能または使用不可にすることができます。また、サイトの要件に基づいて、ルート パターンで操作することもできます。
• Use Calling Party's External Phone Number Mask オプションを選択する場合、外部コールは、コールを発信する IP フォンに指定された発信者番号識別を使用します。このオプションを選択しない場合、Calling Party Transform Mask フィールドに指定されたマスクが、発信者番号識別の生成に使用されます。
ルート リストは、発信コールに使用できるパス(ルート グループ)が優先順位順に並べられたリストです。一般に、1 つのルート リストは、1 つのリモート ロケーションに関連付けられ、複数のルート パターンがそのルート リストを指定することができます。ルート リストの標準的な用途は、リモートの宛先に 2 つのパスを指定することです。この場合、第一選択のパスは、IP WAN を介したパスであり、第二選択のパスは、ローカル PSTN ゲートウェイを介したパスです。
• 複数のルート パターンが同一ルート リストを指すことができます。
• ルート リストは、所定の宛先への代替パスの役目をするルート グループが、優先順位順に並べられたリストです。たとえば、ルート リストを使用して最低料金選択機能をサポートすることができます。この場合、リスト内のプライマリ ルート グループが、コール当たりのコストがより低くなるようにします。プライマリ ルート グループが「all trunks busy(全トランク使用中)」状態、または IP WAN リソースの不足により使用できない場合だけ、セカンダリ ルート グループが使用されます。
• ルート リスト内の各ルート グループは、独自の番号操作を行うことができます。たとえば、ルート パターンが 9.@ であるときに、ユーザが 9-1-408-555-4000 をダイヤルした場合、IP WAN ルート グループは 9-1 を削除し、PSTN ルート グループは 9 だけを削除することが可能です。
• 複数のルート リストに、同じルート グループを含むことができます。ルート グループの番号操作は、そのルート グループを指定(points)する特定のルート リストに関連しています。
• ルート パターンまたはルート グループ内で複数の番号操作を実行しようとする場合、変換が実行される順序が、変換結果の E.164 アドレスに影響を与える可能性があります。Cisco CallManager は、次に示す主要なタイプの番号操作を表示されている順に実行します。
ルート グループは、一般にゲートキーパーまたはリモート Cisco CallManager クラスタとのゲートウェイ(MGCP または H.323)、または H.323 トランクである特定のデバイスを制御し、それを指定します(Cisco CallManager リリース 3.2 以前では、H.323 トランクの役割は、「Anonymous Device」ゲートウェイ、および Intercluster Trunk プロトコルを使用して設定された H.323 ゲートウェイによって実行されていました)。
ルート グループ内のデバイスに順序を割り当てることができます。Cisco CallManager は、指定された順序でデバイスにコールを送信します。発信コールにラウンドロビン順序を使用したい場合は、ルート グループ内のすべてのデバイスの順序を 1 に設定し、サービス パラメータ ReorderRouteList を TRUE に設定してください。これらの設定値を使用すると、優先順位が同じすべてのルート グループ メンバーが、順に選択されてコールをルーティングします。
ルート グループ デバイスは、ルート グループによってアクセスされるエンドポイントであり、一般に、ゲートキーパーまたはリモート Cisco CallManager とのゲートウェイまたは H.323 トランクで構成されます。次のタイプのデバイスは、Cisco CallManager で設定できます。
• H.225 トランク、ゲートキーパー制御:ゲートキーパーを介した標準 H.323 ゲートウェイとのトランク
• インタークラスタ トランク、非ゲートキーパー制御:別の Cisco CallManager クラスタとの直接トランク
• インタークラスタ トランク、ゲートキーパー制御:ゲートキーパーを介した他の Cisco CallManager クラスタまたは H.323 ゲートウェイとのトランク
(注) H.225 トランクとインタークラスタ トランク(ゲートキーパー制御)はどちらも、相手方エンドポイントが標準 H.323 ゲートウェイであるか、Cisco CallManager であるかを自動的に検出し、それに応じて H.225 または Intercluster Trunk プロトコルを選択します(この自動検出メカニズムは、Cisco CallManager リリース 3.2 用にインタークラスタ プロトコルを使用して設定される「Anonymous Device」ゲートウェイにも適用されます)。Cisco CallManager リリース 3.1 より前のリリースで、クラスタとの直接トランクをセットアップしようとする場合は、Intercluster Trunk プロトコルを選択してください。
コール制限を実装するには、Cisco CallManager で次のエレメントを設定します。
パーティションは、ほぼ同じアクセス可能性を持つデバイスのグループです。コール検索スペースは、特定のデバイスからどのパーティションがアクセス可能であるかを指定します。デバイスは、コール検索スペースに含まれているパーティション内のデバイスだけを呼び出すことができます。
コール検索スペースは、特定のデバイスからどのパーティションがアクセス可能であるかを指定します。所定のコール検索スペースが割り当てられるデバイスは、そのコール検索スペースにリストされているパーティションだけにアクセスできます。そのコール検索スペース以外のパーティションの DN へのダイヤルは失敗します。発信者にはビジー信号が聞こえます。
IP フォン回線とデバイス(電話機)自体の両方でコール検索スペースを設定する場合、Cisco
CallManager は、この 2 つのコール検索スペースを連結し、デバイスのコール検索スペースの前に、回線のコール検索スペースを置きます。同じルート パターンが、2 つのパーティション(回線のコール検索スペースに含まれているパーティションとデバイスのコール検索スペースに含まれているパーティション)に指定されている場合、Cisco CallManager は、パーティションの連結リスト内で最初にリストされているルート パターン(この場合、回線のコール検索スペースに関連したルート パターン)を選択します。
(注) Cisco CallManager リリース 3.1 より前のリリースでは、連結は逆順に行われていました。つまり、デバイスのコール検索スペースが先で、その後に回線のコール検索スペースが続きました。
(注) 同じコール検索スペースに含まれているパーティション、または同じ電話機上で設定された異なるコール検索スペースに含まれているパーティションでは、完全に一致するルート パターンを設定しないように強くお勧めします。この方法により、コール検索スペースのパーティションの順序で、どちらを選択するかが決まる場合、ダイヤル プラン ルーティングの予測に関連した問題を回避できます。
結合されたコール検索スペース(デバイスと回線)の最大長は、各パーティション名間の区切り文字を含めて、1024 文字です(たとえば、ストリング「partition_1:partition_2:partition_3」は 35 文字です)。したがって、コール検索スペース内の最大パーティション数は、パーティション名の長さに応じて変動します。また、コール検索スペースの文節は、デバイスのコール検索スペースと回線のコール検索スペースを結合するので、個々のコール検索スペースの最大文字の上限は、512(結合されたコール検索スペース文節の上限 1024 文字の半分)文字です。
したがって、パーティションとコール検索スペースを作成するときは、コール検索スペースに含める予定のパーティション数を基準にして、パーティション名を短くしてください。コール検索スペースの設定の詳細は、次の Web サイトで入手可能なオンラインの『Cisco CallManager アドミニストレーション ガイド』を参照してください。
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/3_3/sys_ad/3_3_2/ccmcfg/index.htm
パーティションまたはコール検索スペースを設定する前に、すべての DN は、<None> という名前が付いた特別なパーティションに置かれ、すべてのデバイスには、<None> という名前が付いたコール検索スペースが割り当てられます。カスタム パーティションとコール検索スペースを作成する場合は、作成するどのコール検索スペースにも、<None> パーティションが含まれています。一方、<None> コール検索スペースには、<None> パーティションだけが入っています。
(注) <None> パーティションに残っているどのダイヤル プラン項目も、コールを発信する任意のデバイスから暗黙的に到達可能です。したがって、予期しない結果を避けるために、<None> パーティションにダイヤル プラン項目を残さないように強くお勧めします。
IP フォンでコール検索スペースを設定する場合は、次のベスト プラクティスをシスコはお勧めします。
• 所定の電話機上のすべての回線に対してダイヤリング権限が一定であることを確実にするために、電話機の個々の回線上ではなく、IP フォン自体でコール検索スペースを設定できます。この方法により、ユーザは、電話機上の別の回線を選択してコール制限をバイパスできません。
• IP フォン回線で自動転送機能を設定する場合、PSTN に到達できるコール検索スペースを選択しないでください。この方法は、ユーザが IP フォンの回線を市外番号に転送し、ローカル IP フォン番号をダイヤルして私用通話の市外通話料金をバイパスすることを防止します。
パーティションに含めることができるダイヤル プラン項目には、IP フォンのディレクトリ番号、変換パターン、ルート パターン、CTI ルート ポイント、および音声メール ポートがあります。
複数のダイヤル プラン項目(ディレクトリ番号、ルート パターンなど)が重複する場合、Cisco CallManager は、ダイヤルされた番号と一致するか、または最も近い(最も固有性の高い一致)項目を選択します。たとえば、ダイヤルされた数字 1111 は、変換パターン 1XXX よりルート パターン 11XX の方が検索性が高いので、この場合、Cisco CallManager は、コールのルーティングにルート パターン 11XX を使用します。
2 つのダイヤル プラン項目が、ダイヤルされたパターンと等しく一致する場合、次のように、一致する項目が同じパーティション内にあるか、異なるパーティション内にあるかによって、動作が決まります。
この場合、Cisco CallManager は、コールを発信するデバイスのコール検索スペース内で最初に表示されるダイヤル プラン項目を選択します。たとえば、ルート パターン 11XX が Partition_A に含まれ、変換パターン 11XX が Partition_B に含まれ、コール側デバイスのコール検索スペースに、Partition_B:Partition_A の順序でパーティションがリストされているとします。この例では、Cisco CallManager は、変換パターン 11XX を一致項目として選択します。これは、変換パターンのパーティション(Partition_B)が、コール側デバイスのコール検索スペース内で最初にリストされているからです。
この場合、Cisco CallManager は、ローカル ダイヤル プラン データベース内で最初にリストされている項目を選択します。
(注) ダイヤル プラン データベースにダイヤル プラン項目がリストされる順序をユーザが設定することはできません。したがって、同じパーティション内で均等一致項目が共存しないようにすることを強くお勧めします。これはこのような場合に発生するダイヤル プラン ロジックが予測できないからです。
次のようにパーティションおよびコール検索スペースを外部ルート パターンと組み合せると、別々のテレフォニー ユーザにサービス クラスを定義することができます。
• 外部ルート パターンをコール可能な宛先に関連したパーティションに置きます。1 つのパーティションにすべてのルート パターンを含めることができますが、コール可能な宛先に応じてルート パターンをパーティションに関連付けると、より高度なコール制限ポリシーを実現できます。たとえば、同じパーティションにローカル ルート パターンと国際ルート パターンを入れる場合、すべてのユーザは、ローカルの宛先と海外の宛先の両方と通信できます。ただし、これは好ましくない場合があります。
• 各コール検索スペースがそのコール制限ポリシーに関連したパーティションのみに到達できるように設定します。たとえば、ローカル コール検索スペースが内部パーティションとローカル パーティションを指定するように設定します。その結果、このコール検索スペースに割り当てられるユーザは、ローカル コールしか発信できません。
変換パターンは、ルート パターンと同じ一般規則に従い、同じワイルドカードを使用します(「ルート パターン」 を参照)。ルート パターンと同じように、変換パターンをパーティションに割り当てます。しかし、ダイヤルされた数字が変換パターンと一致する場合、Cisco CallManager は、ゲートウェイなどの外部エンティティにコールをルーティングしません。代わりに、変換を実行した後、変換パターン内で設定されたコール検索スペースを使用して、コールを再度ルーティングします。
内線番号が重複している場合に、サイト間ダイヤリングを行うために、変換パターンを使用できます。たとえば、サイト 1 とサイト 2 の両方に、範囲 1XXX の内線番号がある場合、重複したディレクトリ番号を分離するために、パーティションを使用する必要があります。サイト間の通信を可能にするために、すべてのユーザから見える共通パーティションで、1 組の変換パターン(サイトごとに 1 つ)が指定されます。サイト 1 の内線番号 1000 を持つユーザが、サイト 2 の内線番号 1000 を持つユーザにダイヤルしようとする場合、サイト 1 のユーザは、まずサイト間アクセス コード(たとえば、8)の後に、宛先サイト コード(たとえば、2)をダイヤルし、その後に続けて相手方の 4 桁の内線番号(この場合、1000)をダイヤルします。この文字列 821000 は、設定された変換パターンと一致します。この変換パターンは、82 を削除し、サイト 2 内部コール検索スペースに 1000 を送信します。このコール検索スペースは、サイト 2 のディレクトリ番号にアクセスできます。
重複した内線番号がある場合のダイヤル プランの設計方法の詳細は、「重複した内線番号のある集中型コール処理」 を参照してください。
単一サイト配置は、通常、すべての外部コールに 1 つのパス PSTN だけを使用するので、ダイヤル プランについては、最も単純な配置です。各ダイヤル プランには、独自の特殊な特性がありますが、単一サイトの配置には、次の一般的な考慮事項が適用されます。
• PSTN へのパスは 1 つしかないので、1 つのルート グループだけが入っている単一ルート リストを使用できます。キャリア A に接続される PSTN トランクとキャリア B に接続される PSTN トランクがあるときに、キャリア A が優先キャリアである場合は、複数のルート グループを設定できます。
• 単一の PSTN ゲートウェイを使用できます。キャパシティを追加したり、冗長性をサポートするために、複数のゲートウェイをルート グループ内のデバイスとして設定できます。
• ルート パターン 9.[2-9]XXXXXX を設定して、7 桁のダイヤリングを許可し、一部のユーザをローカル コールだけに制限するコール制限ポリシーを設定できます。9.[2-9]XXXXXX ルート パターンを、9.1[2-9]XX[2-9]XXXXXX ルート パターンとは別のパーティションに置きます。制限されたユーザのコール検索スペースを 7 桁のダイヤリング ルート パターンをもつパーティションだけを含むように設定します。9.[2-9]XXXXXX ルート パターンを設定する代わりに、すでに設定されている「7 桁のダイヤリング」ルート フィルタを 9.@ ルート パターンに適用することもできます。
• PreDot および Trailing # 数字破棄方法をルート グループに含めます。PreDot の方法は、アクセス コード 9 を削除します。Trailing # の方法は、国際コールのダイヤルの終わりを示すためにユーザがダイヤルする # を削除します。
• コール検索スペースによって作成されるポリシーの詳細設定に基づいて、ルート パターンをパーティションに置きます。これが、9.[2-9]XXXXXX ルート パターンが独自のパーティションに置かれ、国内および国際ルート パターンと一緒のパーティションに置くことができない理由です。
• サイトのコール制限ポリシーごとに別々のコール検索スペースを設定し、必要に応じて、そのコール検索スペースを個々のパーティションに導きます。
• すべての IP フォンをすべてのコール検索スペースから到達可能な内部パーティションに含めます。この設定により、IP フォン同士でお互いにダイヤルできるようになります。
集中型コール処理を使用するマルチサイト IP WAN 配置では、コール処理とアプリケーション(音声メールなど)は集中管理されますが、ダイヤル プランはサイトごとに個別に設計されます。一般に、PSTN ゲートウェイは複数のリモート サイト上に分散されており、リモート サイトのユーザは、PSTN アクセス コードをダイヤルすると、コールがローカル PSTN ゲートウェイから発信されると予想します。さらに、911 などの緊急コールは、常にローカル PSTN ゲートウェイを通過する必要があります。
(注) この項では、複数のサイト間で内線番号は重複していないことを前提としています。内線番号が重複している場合の設計上の考慮事項については、「重複した内線番号のある集中型コール処理」を参照してください。
多くの場合、各サイトでは、緊急時コールはローカル PSTN を使用する必要があります。この要件を実装するには、リモート サイトごとに個別のルート パターンのセットを設定し、そのルート パターンをその特定リモート サイトのユーザだけが到達できるパーティションに置いてください。この推奨事項では、PSTN ゲートウェイが各サイトに置かれていることを前提としています。すべての PSTN ゲートウェイがハブ サイトに集中している場合、ダイヤル プランの設定は、単一サイト配置のダイヤル プラン設定と同じになります。
ほとんどの場合、集中型コール処理配置内のユーザは、リモート ユーザの内線番号をダイヤルするだけで、リモート サイトにコールできます。このタイプのダイヤル プランを実装する場合は、次のガイドラインを適用してください。
• サイト間のオンネット ダイヤリングを構成するために、すべての IP フォンをすべてのリモート サイトのコール検索スペースからアクセス可能なオンクラスタ パーティションに置きます。このモデルでは、リモート サイト間のダイヤル内線番号の重複が考慮されていないことに注意してください。
• 各リモート サイトに、独自のパーティションとルート パターンのセットを指定します。リモート サイトごとのパーティション数は、ルート パターンに関連したコール制限ポリシー数によって異なります。
• 各サイトに、そのサイトの IP フォン用に独自のコール検索スペースのセットを指定します。このコール検索スペースは、適切なローカル ルート パターン パーティションと共に、オンクラスタ パーティションも指定します。
• 必要なコール検索スペースの合計数とパーティションの合計数を計算するには、次の公式を使用してください。
上記の項で説明した方法は、複数の事業所固有のコール検索スペース(事業所のコール制限ポリシーごとに 1 つずつ)を使用して、ダイヤリング権限を実装します。各事業所はローカル コールと緊急コールに別々のゲートウェイを使用する必要があるので、この設定が必要です。
これに代わる方法としては、事業所固有のコール検索スペースを 1 つ作成し、デバイス コール検索スペースを使用して、事業所のすべての電話機に、作成したコール検索スペースを割り当てる方法があります。
事業所固有の単一のコール検索スペースを使用してコール制限を設定するには、次の一般的な方法を使用してください。
• ロケーションごとに無制限のコール検索スペースを作成し、電話機のデバイス コール検索スペースに割り当てます。このコール検索スペースには、電話機のロケーションに適したゲートウェイ(たとえば、同じ場所に配置されている緊急サービス用のゲートウェイと、長距離コール用の中央ゲートウェイ)にコールをルーティングするルート パターンを備えたパーティションが入っていなければなりません。
• ユーザのダイヤリング権限に含まれていないタイプのコールに対するブロック ルート パターンを備えたパーティションを含むコール検索スペースを作成し、ユーザの回線に割り当てます。たとえば、ユーザが国際コール以外のすべてのタイプのコールを利用できる場合、そのユーザの回線は、9.011! に対するブロック ルート パターンを備えたコール検索スペースを使用して設定する必要があります。
この方法の利点として、ロケーションごとに必要な無制限コール検索スペースが事業所に 1 つのみであるという点があります。ダイヤリング権限は、ブロック ルート パターン(ローカル側では重要でない)の使用により実装されるので、同じセットのブロック コール検索スペースをすべての事業所で使用できます。
たとえば、N 個の事業所と 5 つのサービス クラスがあるシステムの場合、必要なコール検索スペースは N+5 個です。この数は、標準的な方法で必要な 5*N 個のコール検索スペースとは大きく異なります。
エクステンション モビリティ機能を使用する場合、電話機のダイヤル制限は、その電話機へのログイン(またはログアウト)中の機能の 1 つになります。ログアウトされた電話機は、他の電話機やサービス(たとえば、米国では 911)のコールを制限する必要があります。一般に、PSTN を通じた市内または市外通話へのアクセスは制限されます。逆に、ユーザがログインしている電話機は、そのユーザのダイヤリング権限に応じてコールを許可し、それらのコールを適切なゲートウェイ(たとえば、同じ場所に配置されているローカル コール用の事業所ゲートウェイ)にルーティングする必要があります。
エクステンション モビリティ使用時のコール制限を設定するには、次の一般的な方法を使用してください。
• ロケーションごとに無制限のコール検索スペースを作成し、電話機のデバイス コール検索スペースに割り当てます。このコール検索スペースには、電話機のロケーションに適したゲートウェイ(たとえば、同じ場所に配置されている緊急サービス用のゲートウェイと、長距離コール用の中央ゲートウェイ)にコールをルーティングするルート パターンを備えたパーティションが含まれていなければなりません。
• ブロック ルート パターンを備えたパーティションを使用してコール検索スペースを作成し、
Default Logout Device Profile 内の回線に割り当てます。ブロック ルート パターンは、ユーザがログインしていないときに許可されるコール(たとえば、緊急サービスや内線電話)を除くすべてのコールをブロックする必要があります。
• ユーザのダイヤリング権限に含まれていないタイプのコールのブロック ルート パターンを備えたパーティションが入っている回線コール検索スペースを使用して、ユーザ デバイス プロファイルを作成します。たとえば、ユーザが、国際コールを除くすべてのタイプのコールを利用できる場合、そのユーザのデバイス プロファイルは、9.011! のブロック ルート パターンを備えたコール検索スペースを使用して設定する必要があります。
重複した内線番号のあるマルチサイト WAN 配置は、複数のサイトで同じ IP フォン内線番号を使用する、特殊なケースの集中型コール処理モデルです。この配置モデルには、次の考慮事項が適用されます。
• 複数のサイトで、1 つの Cisco CallManager クラスタ、および 1 つの音声メール システムまたはユニファイド メッセージング システムを共有できます(単純な集中型コール処理配置でリソースを共有する方法とほぼ同じ)。
• サイト内コールは、省略ダイヤリング(通常、4 桁または 5 桁)を使用して発信できます。
• サイト間コールは、完全な E.164 ダイヤリングを使用するか、アクセス コードの後にサイト コードと内線番号を続けて使用して、発信できます。たとえば、サイト間アクセス コードが 8 であり、サイト コードに 2 桁が使用される場合、ユーザは、8-55-20000 をダイヤルして、サイト 55 の内線番号 20000 にコールできます。
重複した内線番号をサポートすると、Cisco CallManager のダイヤル プラン設定が複雑になります。しかし、このタイプのダイヤル プランは、内線 DN(directory number)が変更できないにもかかわらず、省略ダイヤリングを保持する必要があるシナリオで必要になる場合があります(たとえば、従来からあるレガシー システム、企業買収、または企業合併)。
(注) ダイヤル プランの観点から見ると、重複した内線番号をもつ企業配置の場合と同じ考慮事項が、単一サイトのマルチテナント配置にも適用されます。
重複ダイヤル プランでは、各サイトの IP フォンを別々のパーティションに置いてください。サイトごとに、ローカル PSTN ルート パターンを保持するために、追加のパーティションを定義できます。これらのパーティションの必要数は、設定しようとするサービス クラス数(またはコール ポリシー数)によって決まります。パーティションは、一般に、次のタイプのいずれかになります。
–サイトに置かれているすべての IP フォンの DN を保持します。
–緊急コール、ローカル コール、国内コール、および国際コール用のローカル ルート パターンを保持します。
–音声メール、メディア リソース、およびアプリケーションなどの共有リソースへのアクセスをサポートします。
–サイト間コールのサポートに必要な変換パターンを保持します。
割り当てられているコール ポリシーに従って、これらのパーティションのサブセットが入っているコール検索スペースに IP フォンを割り当てることができます。
(注) この設定は、重複のない集中型コール処理配置に採用された設定(すべての IP フォンを同じパーティションに置く)とは異なります。この場合、IP フォンは、DN が固有ではないので、別々のパーティションに置く必要があります。同じパーティションに置いた場合、自動的に共用ライン アピアランスになります。
一般に、各サイトでは、緊急コールとローカル PSTN コールは、ローカルの事業所 PSTN ゲートウェイを使用する必要があります。このポリシーを設定するには、そのサイトの IP フォンからのみアクセス可能なパーティションに、対応するルート パターンを置きます。
重複したダイヤル プランでは、サイト間コールを発信するには、宛先の完全な E.164 番号をダイヤルするか、サイト間アクセス コードの後に、サイト コードと内線番号を続けて使用します。どちらの場合にも、同じ設計上の考慮事項が適用されます。
サイトとパーティション間の接続性をサポートするために、次のガイドラインに従って変換パターンを使用してください。
• サイトごとに 1 つの変換パターンを定義し、すべての変換パターンをオンクラスタ パーティションに入れます。
• 各パターンは、サイトの E.164 アドレス範囲と一致する必要があります。
• 変換後に得られる着信番号は、サイトの内線番号と一致する必要があります。
• 変換後にコールが送信されるコール検索スペースには、サイトの IP フォンが入っているパーティションが含まれている必要があります。
着信 PSTN コールを適切な内線に送信するには、上記で説明されているオンクラスタ パーティション内の変換パターンが使用できます。オンクラスタ パーティションだけが入っているコール検索スペースに、すべての PSTN ゲートウェイを割り当てます。ゲートウェイが、ダイヤル番号の前に 9 を付け、すでに定義されている変換パターンと一致していることを確認します。
内線番号が重複している場合、音声メール統合には、次の要件に特に注意してください。
• 音声メール ボックスに固有の ID が必要です。つまり、IP フォンの内線番号は音声メール ボックスとして使用できません。固有の番号を取得するには、番号操作が必要です。
• 音声メール システムからの MWI(メッセージ待機インジケータ)メッセージは、固有でない内線番号がある場合でも、適切な IP フォンに到達できなければなりません。
最初の項目は、Voice Mail Profile Configuration ページの Voice Mail Box Mask フィールドを使用して、Cisco CallManager で処理されます。このパラメータを設定すると、音声メール システムと情報を交換し、ユーザを固有に識別できます。たとえば、Voice Mail Box Mask パラメータをユーザに関連した完全な E.164 番号に設定できます。
2 番目の項目は、オンクラスタ パーティション内の変換パターンを再使用することによって処理されます。音声メール システムが完全な E.164 番号を使用して設定されている場合、以前に定義された変換パターンと一致させ、適切なサイト間通信を確保するために、E.164 番号の前に 9 を付けることができます。このように、完全な E.164 番号をもつ音声メール システムからの MWI メッセージは、特定のパーティション内の適切な内線番号に変換されます。
(注) このシナリオには、Cisco CallManager 内の 2 つのサービス パラメータの設定が必要です。Cisco CallManager サービス内の MultiTenantMwiMode パラメータを True に設定し、CMI(Cisco Messaging Interface)サービス内の ValidateDNs パラメータを False に設定する必要があります。
分散型コール処理を使用するマルチサイト IP WAN 配置では、一般に、ダイヤル プランは、オンネット コールの第一選択肢として IP WAN を使用し、IP WAN が使用不能になるか、他の音声コールを処理できない場合、第二選択肢として PSTN を使用するように設定されます。サイト内コールが省略ダイヤリング(たとえば、5 桁のダイヤリング)を使用し、IP WAN または PSTN を介したサイト間コールが、省略なしの完全な E.164 番号を使用することは、このタイプの配置の一般的な要件です。
分散型コール処理モデルに設定可能なルート パターンは数多くあります。一般的には、オンネット コールをプライマリ音声パスとして IP WAN にルーティングするすべてのルート パターンに対して、パスの選択に同じルート リストを使用します。
分散型コール処理を使用するマルチサイト IP WAN のダイヤル プランを設計する場合は、次のベスト プラクティスに従ってください。
• オンネット社内コールのみに IP WAN を使用してください。長距離コールのコストを節約するために、リモート ホップオフ(remote hop-off)をサポートすることも可能ですが、この方法では、ダイヤル プランの設定が複雑になります。
• ゲートキーパー、およびリモート Cisco CallManager またはゲートウェイに完全な E.164 アドレスを送信し、終端デバイスまでそのアドレスを維持して、最終的に有効数字以外のすべてを削除するのが一般的な方法です。この方法により、リモート サイトごとのダイヤル長情報を使用してローカル(発信側)Cisco CallManager を設定する必要がなくなります。
分散型コール処理を使用するマルチサイト IP WAN 配置用のダイヤル プランは、単一サイト配置用のダイヤル プランに似ています。主な相違点は、マルチサイト配置では、IP WAN を介してリモート サイトにアクセスできることだけです。したがって、マルチサイト配置では、通常、少なくとも次の 2 つのルート リストが必要です。
• 外部(オフネット)コールに常に PSTN を使用するルート リスト
• オンネット コールの第一選択パスとして IP WAN を使用し、IP WAN が使用不能になった場合、第二選択パスとして PSTN を使用するルート リスト