Cisco IP テレフォニー ネットワーク デザイン ガイド

ルート パターン

ルート パターンは、ダイヤルされた番号（北米では 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 の変換テーブルを設定できます。

この例では、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 では、完全な 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.!

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

Option 2: Route Pattern = 0.!#

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

パーティション

パーティションとは、同じような到達特性を持つデバイス グループのことです。パーティションに配置できるデバイスは、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 つのパーティション（内部ローカル サイトユーザ用と外部コール用）が、所定サイトの到達可能性の特性を定義します。デバイスとルート パターンがこれらのパーティションに配置されます。

この例は、複数サイト 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」で説明します。