Cisco IP テレフォニー ネットワーク デザイン ガイド
ダイヤル プランのアーキテク チャと設定
ダイヤル プランのアーキテクチャと設定
発行日;2012/01/13 | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

ダイヤル プランのアーキテクチャと設定

Cisco CallManager ダイヤル プランのアーキテクチャ

ルート パターン

ルート リスト

ルート グループ

デバイス

ディジット変換テーブル

特別なダイヤル数字列の考慮事項

オンネット ルート パターン

PSTN を介した送信コール

ダイヤル プラン グループとコール制約条件の設定

パーティション

コール検索スペース

ダイヤル プランのガイドラインと設定

キャンパスと個別サイトのダイヤル プラン

複数サイト WAN のダイヤル プラン

ゲートキーパーの役割

ダイヤル プランのアーキテクチャと設定

この章では、Cisco CallManager ダイヤル プランのアーキテクチャ、およびオペレーションについて説明し、設計上の推奨事項を述べます。ダイヤル プランとは、本質的にテレフォニー システムのインタフェースです。これにより、ユーザは、システムがさまざまなロケーションへ送付することができるダイヤル数字列を使用して、お互いに容易に通信することができます。

この章は、次の主要なセクションで構成されています。

「Cisco CallManager ダイヤル プランのアーキテクチャ」

「特別なダイヤル数字列の考慮事項」

「ダイヤル プラン グループとコール制約条件の設定」

「ダイヤル プランのガイドラインと設定」

「ゲートキーパーの役割」

Cisco CallManager ダイヤル プランのアーキテクチャ

このセクションでは、ダイヤル プランのアーキテクチャと機能コンポーネントについて説明します。ダイヤル プランは、多くの方法で設定できるため、推奨できる設定方法についても説明します。

ダイヤル プランの要件には、発信元に透過的な冗長パスだけではなく、4 桁あるいは 5 桁の内線番号のような、短縮ダイヤルのサポートも含めることができます。Cisco CallManager Release 3.0 のダイヤル プランでは、スケーラビリティ、柔軟性、および使いやすさが格段に改善され、同時に Cisco CallManager と Cisco IOS ゲートウェイのより緊密な統合は、大規模なネットワークの配備を可能にしました。

Cisco CallManager ダイヤル プランのアーキテクチャでは、次の 2 つの一般的なコールのタイプを処理するように設定します。

Cisco CallManager クラスタ自体に登録されている Cisco IP 電話への内部コール

PSTN ゲートウェイを介した、あるいは IP WAN を経由した別の Cisco CallManager クラスタへの外部コール

図 5-1は、これら 2 つのタイプのコールを処理するように設計されたネットワークを示しています。適切に設計したダイヤル プランでは、音声コールは、IP WAN を優先して使用し、IP WAN が停止あるいは使用不可能な場合にだけ、PSTN へルーティングされます。このルーティングは、ユーザには透過的です。

図 5-1 適切に設計されたダイヤル プランが目標とするネットワーク

 

Cisco CallManager クラスタに登録された IP 電話への内部コールのダイヤル プランは、かなり簡単です。初期設定で、どこへ移動しても維持されるディレクトリ番号(DN)を IP 電話に割り当てます。IP 電話を Cisco CallManager クラスタに登録するたびに、IP 電話は、その同じディレクトリ番号を維持すると同時に、その新しい IP アドレスを用いて、動的に Cisco CallManager クラスタを有効にアップデートします。内部コールに使用する内部ダイヤルの長さ(ダイヤルする桁数)は設定できます。


) IP 電話は、この方法でアクセスできる唯一のデバイスではありません。Cisco CallManager に登録され、ディレクトリ番号を維持するその他のデバイスとしては、MGCP、あるいは Skinny Gateway Protocol を使用するゲートウェイに接続された、Cisco IP SoftPhone、アナログ電話、およびファックス マシンがあります。


外部コールを処理するように Cisco CallManager を設定するには、ルート パターンを使用する必要があります。多くの場合、ルート パターンは、PSTN ゲートウェイへコールを送出するために使用されますが、IP WAN のコールをリモート Cisco CallManager へ転送する場合にも使用されます。Cisco CallManager Release 3.0 のダイヤル プランのアーキテクチャは、ネットワーク要件に基づくディジット処理だけではなく、所定のダイヤルされた番号に複数のルートを許容する 3 層の決定ツリーです。ディジット処理とは、元々ダイヤルされた番号にディジットを追加、あるいはその番号からディジットを取り去り、ユーザがダイヤルするときの習慣、あるいはゲートウェイの要求に適応できるようにするタスクです。ゲートウェイの冗長性に必要なトランク グループや、コストが最も安いルーティング方式のような機能も設定できます。

代替ルート選択の例として、所定のダイヤルされた番号に対するパスは、通常、最初の選択肢として IP WAN を取得しますが、IP WAN が停止状態、あるいは IP WAN に十分なリソースがない場合、二番目の選択肢として PSTN を取得します。代替ルートを使用するためのダイヤル プランの基準は、コール アドミッション制御メカニズムの指示によることもあります。その指示とは、ゲートウェイでは不十分なトランクしか利用できない、つまり IP WAN はコールを受け付けられないことを意味します。

図 5-2は、代替ルートの選択をサポートする、Cisco CallManager Release 3.0 のダイヤル プランのアーキテクチャを示しています。このアーキテクチャの要素については、次のサブセクションで説明します。

図 5-2 Cisco CallManager ダイヤル プランのアーキテクチャ

 

ルート パターン

ルート パターンは、ダイヤルされた番号(北米では E.164 番号)を識別し、基本的なルート リストとルート グループの設定を使用して、コールのルーティング方法を決定します。ルート パターンを特定の番号として、あるいはより一般的に、ある番号範囲として入力できます。ルート パターンを使用して番号範囲を表すことで、必須エントリの数を最少限にします。

ルート パターンがダイヤルされた番号に一致すると、コールは、このルート パターンに関連付けられたルート リストに渡されます。コールをルート リストに渡す前に、一致したルート パターンにディジットを追加する、あるいはそこからディジットを削除することが必要となる場合には、ディジット処理が発生することがあります。その後、ルート リストは、指示した優先順位に基づきコールを受信する、ダウンストリームのルート グループ(トランク グループ)を決定します。


) ディジット処理は、送信コールのルート パターンにだけ発生し、その後、送信コールはルート リストとルート グループに送信されます。個別のダウンストリーム ルート グループは、同じルート パターンに対して固有のディジット処理を行うことができます。ダイヤルされた所定の番号に使用される別のルートが、別のディジット処理を必要とする可能性がある場合、この機能が特に役立ちます。たとえば、4 桁の内部ダイヤル プランを持つリモート ロケーションに到達するために、ユーザが、7 桁をダイヤルしなければならないことが考えられます。IP WAN を通過する場合、最初の 3 桁が削除されることにより、残りの 4 桁が、そのネイティブの内部ダイヤル数字列の長さで、リモートの Cisco CallManager に配布されることになります。IP WAN が停止しているか、または追加の音声コールを IP
WAN が許容できない場合、ダイヤルされた 7 桁の前に、PSTN を介して着信側に到達するためのエリア コードを付加する必要があります。1 つのルート パターンに関連付けられるルート リストは 1 つだけです。


ルート リスト

Cisco CallManager の以前のリリースで使用されていた用語「route point」は、
Cisco CallManager Release 3.0 では、機能はほぼ同じですが、「route list」に代わりました。ルート リストは、コールがルート指定される経路を定義します。ルート リストを設定して、トランク グループの目的に効果的に役立つ 1 つ、あるいはそれ以上のルート グループを指定します。ルート リストは、設定された優先順位で所定のコールをルート グループに送信します。たとえば、プライマリ ルート グループは、より安いコストをコールに提供します。その一方で、すべてのトランクが使用中の状態、あるいは IP WAN のリソースが不足しているために、プライマリが使用できない場合、セカンダリ ルート グループが使用されます。

ルート グループ

ルート グループは、ゲートウェイのような特定のデバイスを制御します。ゲートウェイは、Skinny Gateway Protocol、MGCP、あるいは H.323 を基に作動します。NetMeeting クライアント、あるいはリモート Cisco CallManager のような IP WAN にまたがるエンドポイントは、H.323 ゲートウェイとして設定されます。ルート グループは、1 つあるいはそれ以上のデバイスをポイントし、コールのルーティングに必要なデバイスを優先順位に基づいて選択できます。ルート グループは、すべてのコールをプライマリ デバイスに導きますが、プライマリが使用できないときは、セカンダリ デバイスを使用します。このようにして、トランク グループとして効果的に作動します。

1 つあるいはそれ以上のルート リストは、同じルート グループをポイントできます。所定のルート グループのすべてのデバイスに、パスおよびディジット処理のような同じ特性をもたせることができます。ルート グループにディジット処理を実行する能力を割り当て、ルート パターンのディジット処理を上書きできます(「ルート パターン」を参照してください)。

デバイス

すべての IP エンドポイントはデバイスと見なされますが、ルート グループのメンバーになれるのは一定のデバイスだけです。図 5-3は、ルート グループのメンバーになれるデバイスのタイプを示しています。

図 5-3 ルート グループがポイントするデバイス タイプ

 

次の注釈が図 5-3 のデバイスに適用されます。

H.323 ゲートウェイは、制御されたゲートキーパーとして設定できます。このことは、コールからのゲートウェイへの照会が正常に終了しなければ、コールは H.323 デバイスに送られないことを意味します。リモート Cisco CallManager となる H.323 デバイスだけを、制御されたゲートキーパーとして設定する必要があります。

デバイスへのコールが使用するコーデックを選択する際には、必要なタイプのコーデックを使用する領域にデバイスを配置してください。

MGCP あるいは Skinny Gateway Protocol に基づくゲートウェイは、単一の Cisco CallManager クラスタ専用ですが、H.323 ゲートウェイは、受信コールと送信コールに対して複数のクラスタで共有できます。

ルート パターンのダイヤル構造の重要な機能の 1 つは、このダイヤル構造が、IP 電話のコールが、H.323 を使用してゲートウェイあるいは Cisco CallManager に送られるときに、通常、使用されることです。これらのケースで、宛先へのプライマリ パスが使用できない場合には、代替ルートが取得されます。すべてのサイト間コールが、IP WAN をプライマリ パスとして、PSTN をセカンダリ パスとして取得するこの方式については、第 6 章「分散型コール処理を行う複数サイト WAN」で説明します。

同じ Cisco CallManager、あるいは Cisco CallManager クラスタに存在する IP 電話間のコールは、ルート パターンのダイヤル構造を使用しないため、IP 電話間で接続が切断された場合、代替ルートを使用できません。2 つの IP 電話間で IP 接続が切断される場合、その理由の多くは、その電話の 1 つと Cisco CallManager との間の接続が切断されたためです。たとえば、このことは、中央集中型コール処理を行う複数サイト WAN の配備で発生する可能性があります。このような場合、サイト間での代替ルーティングはありません。

ディジット変換テーブル

Cisco CallManager はディジット変換をサポートします。ディジット変換とは、着信番号と発信番号を、ディジット数の変更を含め他の番号に変換する機能です。ディジット変換は、外部コールの受信あるいは送信に対してだけではなく、内部コールの受信あるいは送信にも適用されます。

変換テーブルの共通用途は、未割り当てのダイヤルイン方式(DID)番号がダイヤルされた時に、その番号をコンソール使用者に送信することです。たとえば、1000 ~ 1999 の範囲の DID があり、未割り当ての番号へのすべてのコールを内線 1111 にいるコンソール使用者に送信したいと仮定します。次のようにして、1111 の変換マスクをポイントする 1XXX の変換テーブルを設定できます。

 

変換テーブル
変換マスク

1XXX

1111

この例では、Cisco CallManager は、ワイルドカードを使用して、最長の一致検索を実行します。1000 ~ 1999 の範囲で一致ディレクトリ番号を持つ IP 電話がある場合、Cisco CallManager はコールをその電話に送信します。1000 ~ 1999 の範囲で一致する IP 電話番号がなく、1XXX 変換テーブルで一致がある場合、そのコールは、内線 1111 へ送信されます。

ディジット変換は、受信コールと送信コールの両方に同じディジット変換式を適用する「発着信側変換」を使用して、ルート パターン構造内でも実行できます。このことは、ルート パターン内で、次の 3 つのタイプのディジット処理を、送信先番号に対して実行できることを意味します。

ディジット廃棄

着信側変換マスクの適用

ディジットのプレフィックス

次の例では、2.XXXX のルート パターンを定義します。発信番号は 1000 ですが、444XXXX の着番号と 919392XXXX の発番号を使用して、コールを PBX に送る必要があります。Cisco CallManager のルート パターンは、次のように処理されます。


ステップ 1 919392XXXX の発番号変換マスクが適用されます。これにより、プレフィックス 91939 が発信番号の前に付きます。

ステップ 2 アクセス コード(2)は破棄され、XXXX だけを残します。

ステップ 3 ディジット 444 をプレフィックスとして付けます。


 

ステップ 2 と 3 を遂行する代替としては、444XXXX の着番号変換マスクを使用することになります。

発番号変換マスクは、発信番号にだけ適用され、その他のマスクは着信番号に適用されることを覚えておくことが重要です。Cisco CallManager は、最初に、ディジットを廃棄し、次に変換マスクを適用し、最後にディジットをプレフィックスとして付けます。

特別なダイヤル数字列の考慮事項

作成するダイヤル プランはできる限り簡単にして、エントリ数は最少限にする必要があります。これを実現するための最も効果的な方法は、ネットワーク(IP WAN)上のロケーションにだけ特別なダイヤル プランを設定します。そして、IP WAN が停止しているか、IP WAN に十分なリソースがない場合、 IP WAN のコールに対して 9 あるいは 0(ゼロ)のような、ローカルの PSTN ゲートウェイ アクセス コードを使用するだけでなく、PSTN を経て到達する必要があるロケーションに対しても、これを使用することです。これらのアクセス コードは、それぞれ、オフネットルート パターン、およびオンネットルート パターンと呼ばれます。

オンネット ルート パターン

分散型コール処理を行う複数サイト IP WAN では、完全な E.164 アドレスの省略形を、通常、短縮ダイヤルとして使用します。たとえば、オンネット ロケーションの番号範囲が、(408)526-1000 ~ 1999 の場合、61XXX のエントリを持つ単一の ルート パターンだけが存在する可能性があります。このことは、ユーザのダイヤル操作を簡単にし、X をワイルドカードとして利用できるルート パターン エントリが、1 つだけ必要になります。

リモート Cisco CallManager を内部ダイヤル プラン用の適切な桁数で表すために、Cisco CallManager のルート パターンは、ダイヤルされた番号からディジットを取り除く、あるいはこの番号の前にディジットを付けることもできます。事実、IP WAN 上のすべてのコールに対して、リモート Cisco CallManager に提供される桁数は、リモート サイトで内部コールに使用し、ダイヤルするディジットの長さに一致する必要があります。リモート Cisco CallManager は、単にディジットを調べ、コールをルーティングするだけです。着信コールに対するディジット処理はありません。

IP WAN リソースが、ある環境で不足しており、コールを PSTN を通じて送信する必要がある場合、PSTN ゲートウェイに対するルート グループには、エリア コードおよび 3 ディジット交換を挿入する必要があります。Cisco CallManager の初期のリリースでは、すべての所定ルート パターンに使用できるディジット処理テーブルは、1 つしかありませんでした。その時点では、Cisco IOS ゲートウェイが、エリア コードと 3 ディジット交換を挿入できたので、使用できるのは、Cisco IOS ゲートウェイだけでした。この管理的な負担は、Cisco CallManager Release 3.0 で削除されました。このリリースには、各ルート グループに対して、固有のディジット処理を実行できる能力があります。このリリースでは、サイト別の単一ポイントのダイヤル プラン管理、ならびに Cisco IOS ゲートウェイ、および Skinny Gateway Protocol に基づくゲートウェイ両方の使用が許されています。

図 5-4は、PSTN をバックアップとして使用し、パスごとに異なるディジット処理が必要になる、IP WAN 上でのオンネット コールを示しています。

図 5-4 パスごとに異なるディジット処理を行う IP WAN 上でのコール

 

PSTN を介した送信コール

PSTN を介した送信コールは、通常、単一のルート パターンだけを必要とします。これが PSTN トランク アクセス コードで、普通は 9 あるいは 0(ゼロ)となります。北米では、ルート パターン 9.@ を設定することにより、9(最も一般的に使用されている)と 7 桁、あるいは 1+10 桁の電話番号をダイヤルするだけで、ユーザは外部コールを行えます。Cisco CallManager の初期のリリースで使用していたローカル エリア コードの概念は、Cisco CallManager Release 3.0 ではなくなりました。ローカル エリア コードは、一部人口の多いエリアで使用されていますが、1 をダイヤルする必要はありません。ローカル エリア コードが必要な時は、特定のエリア コードに対して、1 を使用しないルート パターンを設定する必要があります。これにより、Cisco CallManager は、ローカルの 7 桁番号とローカル エリア コードとを区別でき、ダイヤル操作が完了した時期を判別することができます。完了したときを判別できない場合、Cisco CallManager は、ディジットをまったく検出することなく 10 秒待機した後、ダイヤル操作が完了したと想定します。

ローカル PSTN ゲートウェイのダイヤル プランの設定は非常に簡単です。MCGP と Skinny Gateway Protocol に基づくゲートウェイは、Cisco CallManager に設定されたそれぞれのゲートウェイのダイヤル プラン情報のすべてを必要とするのに対して、H.323 ベースの Cisco IOS ゲートウェイは、通常、最少のダイヤル ピア数だけを必要とします。これらのダイヤル ピアは、すべてのコールを
Cisco CallManager から PSTN へ送信するために、ゲートウェイが使用します。このタイプのダイヤル プランの例として、図 5-8で示されている設定を参照してください。

北米の外では、多くの場合、各国でダイヤル数字列の長さは異なります。複数の長さのダイヤル プランは、ユーザが特定のルート プランを指定しない限り、Cisco CallManager が、ダイヤル操作が完了した時期を認識できないという問題を提起します。Cisco CallManager は、デフォルトでは、ディジットを何も受信せずに 10 秒待機し、それからダイヤル操作が完了したと想定します。北米の外では、PSTN アクセスに対するルート パターンを設定する場合、次の 2 つの共通オプションを適用します。普通、ローカル PSTN アクセス コード、0(ゼロ)を使用します。

Option 1: Route Pattern = 0.!

 

0.

ローカル PSTN アクセス コードを表現

!

すべてのディジット、およびいずれかの数のディジットを表現。これは、Cisco CallManager がダイヤル操作が完了したと想定して、コールを送信する前に、いかなるディジットも受信せずに 10 秒(デフォルト)待機する必要があることも意味しています。

Cisco CallManager サービス パラメータ中のアイドル ディジット待機タイマーを、たとえば 3 秒に短縮すれば、10秒間待たずにコールを送信できます。ただしこれを実施すると、ユーザがダイヤル操作中にわずかに休止した場合、Cisco CallManager がダイヤル操作が完了したという誤った判断を下すというリスクがあります。

Option 2: Route Pattern = 0.!#

 

0.

ローカル PSTN アクセス コードを表現

!

すべてのディジット、およびいずれかの数のディジットを表現。これは、Cisco CallManager がダイヤル操作が完了したと想定して、コールを送信する前に、いかなるディジットも受信せずに 10 秒(デフォルト)待機する必要があることも意味しています。

#

ユーザが #(ポンド)キーを押すと、Cisco CallManager はダイヤル操作が完了したと想定して、すぐにコールを送信しなければならないことを表示。

このオプションでは、ユーザは、ダイヤル数字列を終了し、すぐにコールを開始するには、# キーを押すべきであることを指示されます。この場合、何らかのユーザ トレーニング、およびお客様によるこれまでのダイヤル操作の習慣の変更が必要となります。ただし、この操作は、実際にはセル電話の送信ボタンを押すのと同じことです。

ダイヤル プラン グループとコール制約条件の設定

Cisco CalManager Release 3.0 の新機能の 1 つが、電話別にコール制約条件を設定し、同じ Cisco CallManager に複数の制限されたダイヤル プラン グループを作成する能力です。同じ Cisco CallManager 上のユーザは、同じコール制約条件とダイヤル プランをもつコミュニティにグループ化できます。異なるコミュニティは、独自に作動しますが、ダイヤル プランが同じであるばかりでなく、同じゲートウェイを共有します。中央集中型コール処理を行う複数サイト IP WAN 上で特定の利害対象となるこれらの新機能は、次に説明する パーティション コール検索スペース を使用して実現されます。

パーティション

パーティションとは、同じような到達特性を持つデバイス グループのことです。パーティションに配置できるデバイスは、IP 電話、ディレクトリ番号、およびルート パターンです。おのおののパーティション名は、そのパーティションが表示するユーザのグループと意味のある相関関係をもつものを選択する必要があります。たとえば、San Jose のビルディング D にいるユーザには、SJ-D という名称のパーティションを作成できます。

コール検索スペース

コール検索スペースとは、ユーザがコールを開始する前に検索できるパーティションの順位リストです。コール検索スペースは、コールを開始できるデバイスに割り当てられます。これらのデバイスには、IP 電話、Cisco SoftPhone、およびゲートウェイがあります。

ユーザがダイヤルできるのは、ユーザに割り当てられたコール検索スペースにあるパーティションだけであるため、ダイヤル操作の制約条件の起動は簡単です。許可されたパーティション外のディレクトリ番号をダイヤル操作すると、発信者は使用中信号を受信します。

パーティション、コール検索スペースとアクセス管理リストをもつルータとの間の類似点を引き出せます。ユーザを所属させる IP サブネットとして 1 つのパーティションを考えます。コール検索スペースは、到達可能なサブネットを指定する受信 ACL に似ています。

図 5-5は、パーティションおよびコール検索スペースの ACL に対する類似を表しています。

図 5-5 パーティション、コール検索スペースのサブネット、ACL との類似点

 

図 5-6は、パーティションとコール検索スペースを使用して、ダイヤル操作の制約条件を提供する方法を示す簡単な例です。

図 5-6 ダイヤル操作の制約条件の提供に使用するパーティションとコール検索スペース

 

図 5-6では、従業員のダイヤル操作に制約条件はありませんが、ロビーの電話は、ローカル サイト内の人にだけ電話をかけることができます。すべての IP 電話が SJ-Users パーティションに配置され、PSTN と結合しているルート パターン 9 が SJ-PSTN パーティションに配置されています。2 つのコール検索スペースが作成され、2 つの異なるダイヤル操作特性を示しています。Unrestricted と呼ばれるコール検索スペースが作成され、SJ-Users と SJ-PSTN の 2 つのパーティションを含んでいます。SJ-Only と呼ばれる 2 つめのコール検索スペースが作成され、SJ-Users だけを含んでいます。San Jose の従業員の IP 電話には、どこにでもダイヤルできる Unrestricted のコール検索スペースが割り当てられています。ロビーの電話には、ローカル サイト内のローカル電話にだけダイヤルできる、SJ-Only と呼ばれるコール検索スペースが割り当てられています。

前述の例で設定に使用したパーティションとコール検索スペースの割り当てを、表 5-1表 5-2に示します。2 つのパーティション(内部ローカル サイトユーザ用と外部コール用)が、所定サイトの到達可能性の特性を定義します。デバイスとルート パターンがこれらのパーティションに配置されます。

 

表 5-1 パーティションの割り当て

パーティション名
パーティションに割り当てられる指定デバイス

SJ-Users

San Jose 内のすべての IP 電話

SJ-External

すべての外部宛先ルート パターン(ローカル PSTN)

 

表 5-2 コール検索スペースの割り当て

コール検索スペース
パーティション
割り当て先

Unrestricted

SJ-Users
SJ-External

内部コールと外部コールが実行可能なデバイス

SJ-Only

SJ-Users

内部コールだけが実行可能なデバイス

この例は、複数サイト WAN ローカル コール処理の要件に関して、おそらく最も簡単な設定を示しています。次の事項を考慮して、より大がかりなダイヤル プランを作成できます。

サイト内コールだけ

サイト内コールとローカル緊急コールだけ

サイト内コールとサイト間コールだけ

サイト内コール、サイト間コール、およびローカル緊急コールだけ

サイト内コール、サイト間コール、ローカル緊急コール、およびローカル PSTN コールだけ

サイト内コール、サイト間コール、ローカル緊急コール、および国内長距離 PSTN コールだけ

国際番号を含めた完全無制限のダイヤル操作

パーティションとコール検索スペースにより、パーティション ベースで独自のダイヤル範囲を設定できます。このことは、別のパーティション内の内線番号とアクセス コードは、重複した番号であっても、それぞれ独自の機能をもつことができることを意味します。この点で最も共通する用途が、中央集中型コール処理システムです。このシステムでは、すべての サイトとユーザが同じ
Cisco CallManager を共有しますが、各サイトは、9 をダイヤルしてローカルの
PSTN にアクセスできます。これが、Cisco CallManager Release 3.0 での新しい機能です。前のリリースでは、リモート サイトごとにサイト独自の PSTN アクセス コードをもつ必要がありました。

中央集中型コール処理システムを使用している異なるサイトのユーザと内線番号の重複に関しては、次の条件を適用します。

異なるサイトで内部ダイヤル プランの重複がサポートされるのは、音声メールが不要な場合だけです。Cisco CallManager はコールを音声メールに送信するとき、Cisco CallManager は、そのコールの宛先であるパーティション(および、それに伴う音声メール ユーザ)を判定できません。たとえば、コールが音声メールに送信されると、サイト A のユーザ 1111 をサイト B のユーザ 1111 と区別できません。音声メールのユーザには固有の ID を割り当てる必要があります。

音声メールが不要の場合、異なるサイトで内線番号を共有するユーザは、次の方法で到達できます。

PSTN :ローカル アクセス コードの後に完全修飾のディレクトリ番号を続けてダイヤル操作する方法

IP WAN :変換テーブルを使用する方法。変換テーブルを使用すると、コールが宛先のパーティションに配信された時に取り除かれる、固有のステアリング コードを重複する番号の前に付けることができます。

ダイヤル プランのガイドラインと設定

ダイヤル プランの複雑性は、コールをルーティングできるパスの数に応じて異なります。このセクションでは、典型的なダイヤル プランのシナリオについていくつか説明します。

キャンパスと個別サイトのダイヤル プラン

複数サイト IP WAN の接続を使用しないキャンパス環境で、ダイヤル プランに関する最も共通する考慮事項は、PSTN アクセスの提供に関することです。

図 5-7では、次のダイヤル操作の規則が適用されています。

内部ダイヤル操作用には、 5 桁

すべての長距離コール用には、 PSTN アクセス コード(9)、および 1 + 10 桁の番号

外部、ローカル コール用には、 9 + 7 桁の番号

この例では、PSTN に対するゲートウェイ障害時、あるいはトランク障害時に提供される、ゲートウェイの冗長性についても示しています。PSTN ゲートウェイは、H.323 を使用する Cisco IOS ゲートウェイです。

図 5-7 孤立したキャンパスでの共通ダイヤル プラン

 

このモデルでのダイヤル プランの設定には、単一のルート パターンだけが必要となることに注意してください。9.@ は、9 がローカルの PSTN アクセス コードを、そして、@ はこの場合、北米でのダイヤル操作プランを示しています。北米でのダイヤル操作のためルート パターン 9.@ には、911 サービスが含まれます。ルート グループは、ディジット処理でアクセス コードを廃棄するように設定されています。これにより、この場合は Cisco IOS である、ローカル PSTN ゲートウェイに送信される数字列から 9 が除かれます。Cisco CallManager は、ドット(.)の左側にあるすべてのディジットをアクセス コードとして示しているため、アクセス コード廃棄機能を選択すると、ドットの左側にあるすべてのディジットが取り除かれることになります。


) このルート グループの例では、2 つのゲートウェイが優先順位順に記載されています。この例は、すべてのトランクが使用中の状態、あるいはゲートウェイ障害の時に、ゲートウェイの冗長性がどのように実現されるかを示しています。


図 5-8は、各 Cisco IOS PSTN ゲートウェイに必要な設定を示しています。目標は、できる限り少ないエントリで Cisco IOS H.323 ゲートウェイを設定することです。すべてのダイヤル プランの設定を Cisco CallManager で行えることが理想です。このことは、MGCP あるいは Skinny Gateway Protocol に基づくゲートウェイでは可能ですが、より多く使用されるゲートウェイは、H.323 ベースのものです。

図 5-8 Cisco IOS PSTN ゲートウェイの設定

 

この設定では、PSTN への長距離コールには、1+10 桁のダイヤル操作を、そしてローカル PSTN のコールには、7 桁のダイヤル操作を必要とすることを想定しています。

9.@ ルート パターンの範囲には、緊急 911 サービスが含まれていますが、
Cisco IOS H.323 ゲートウェイでは、911 に対するダイヤル ピアも必要となります。9.@ ルート パターンの範囲に含まれている 411 および 611 のサービスに対しても、同じように異なるダイヤル ピアを追加できます。

「PSTN を介した送信コール」で前述したように、ローカル エリア コードをルート パターンを使用して特別に設定し、1 を不要にする必要があります。

複数サイト WAN のダイヤル プラン

複数サイト WAN システムのダイヤル プランについては、第 6 章「分散型コール処理を行う複数サイト WAN」、および第 7 章「中央集中型コール処理を行う複数サイト WAN」で説明します。

ゲートキーパーの役割

分散型コール処理環境では、ゲートキーパーを使用して、WAN 全体でのコール アドミッション制御を実現できます。Cisco CallManager Release 3.0(5) を導入すると、ゲートキーパーを使用して、Cisco CallManager 間のダイヤル プランを簡素化することもできます。

たとえば、2 つの Cisco CallManager のサーバが、WAN を経由して接続されていると想定します。1 つの Cisco CallManager には 1XXX の内線番号範囲が、そしてもう 1 つには 2XXX の範囲があり、両方とも、コール アドミッション制御のためのゲートキーパーに登録されています。おのおのの Cisco CallManager には、それぞれのダイヤル プランのルート パターン設定に適切なエントリがあります。そのルート パターン設定は、番号非通知呼び出しデバイス機能を使用して、ゲートキーパーに対して、もう一方の Cisco CallManager の内線番号範囲を指示します。実際には、サブスクライバ 1001 がサブスクライバ 2002 にダイヤルすると、Cisco CallManager 1XXX は、アドレス解決のために 2002 をゲートキーパーに送信します。次に、そのゲートキーパーは、Cisco CallManager 2xxx の IP アドレスを Cisco CallManager 1XXX に送信し、サブスクライバ 2002 の IP アドレスを確定します。コール アドミッション制御基準を満たしていれば、ゲートキーパーは、そのコールの確立を許可します。図 5-9は、この例を示しています。

図 5-9 コール アドミッション制御のためのゲートキーパーの使用

 

このシナリオで WAN を使用できない場合、そのコールは、ダイヤルされたようには通過できません。Cisco CallManager 1XXX が、ひとたびそのコールが配置できないと通知されると、それ以上のメカニズムがインテリジェント ディジット処理にないため、利用できる自動フォールバックはありません。(たとえば、Cisco CallManager は、最初にダイヤルされたディジットに付加すべきエリア コードとプレフィックスを判断できません。)その時点で、発信側のサブスクライバは、PSTN のような代替ルートを経由するコールの確立を試行する必要があります。

ダイヤル プランの簡素化、およびPSTN へのフォールバックの提供をこのシナリオで希望するのであれば、10 桁のダイヤル操作を使用してください(あるいは、国内のダイヤル プランを固守してください)。たとえば、NANP(North American Numbering Plan)では、XXXXXXXXXX のルート パターンが、アドレス解決のためにコールをゲートキーパー(番号非通知デバイス)に送ります。そのゲートキーパーが、コールが WAN を越えることを許可しない場合、
Cisco CallManager は、プレフィックス 91 をダイヤルされたディジットに付加して、コールが PSTN を経由して再ルーティングされるようにします。