Cisco Unified Communication ソリューション リファレンス ネットワーク デザイン (SRND) Cisco Unified CallManager Release 5.0

ダイヤル パターン認識

ユーザが電話機でダイヤルする番号ストリングは、一般的にパターンに従っています。たとえば、多くの企業では、同じオフィス ロケーション内で行われるコールに 5 桁の省略ダイヤリング パターンを使用しています。また、多くの企業では、外部へのダイヤリングを表すのに 1 桁のアクセス コードを用い、その直後に何桁かの番号をダイヤルして、ローカル公衆網の番号または長距離公衆網の番号に到達します（たとえば、ローカル番号への到達には 9 に続く 7 桁の番号を使用し、長距離の通話先への到達には 9 の後に 1 と 10 桁の番号をダイヤルします）。

システム管理者は、このようなパターンのシステムによる認識を計画し、あらかじめ決められたパターンに対応するストリングが検出されると同時にシステムが素早く反応し、ユーザがダイヤル後に遅延を感じない（または、その遅延が最小になる）ようにする必要があります。

Skinny Client Control Protocol（SCCP）を使用する電話機、およびダイヤル中に Keypad Markup Language（KPML）を使用する SIP 電話機の場合、パターン認識を実装するには、Cisco Unified CallManager でルート パターン、トランスレーション パターン、電話機 DN などを設定します。ユーザが 1 つの桁をダイヤルするたびに、電話機から Cisco Unified CallManager へシグナリング メッセージが送信され、一致するパターンを認識する差分処理が行われます。ユーザ入力に含まれる個々のキー操作が収集されるたびに、Cisco Unified CallManager の番号分析は次のような適切なユーザ フィードバックを提供します。

• 電話機が最初にオフフックになったときにダイヤル トーンを再生する。

• 番号がダイヤルされたらダイヤル トーンを停止する。

• 特定の番号のシーケンスがダイヤルされた場合、たとえば、オフネット アクセス コードの 9 がダイヤルされたときなどに、2 次ダイヤル トーンを提供する。

番号のダイヤリングが完了すると、Cisco Unified CallManager はユーザ フィードバックとしてコールプログレストーンを提供します。たとえば、通話先がアラート段階ならばリングバック トーン、通話先が無効であればリオーダー トーンを再生します。

SIP（Session Initiation Protocol）を実行する IP Phone には、設定に SIP ダイヤル規則というパターン認識命令を使用できます。この命令を使用すると、電話機内でパターン認識の大部分のタスクを実行できます。あるパターンが認識されると、SIP 電話機はユーザの入力に対応する番号にコールを発信するために、Cisco Unified CallManager に発信要求を出します。この動作は SIP INVITE と呼ばれ、SCCP プロトコルを実行している IP Phone からのコールと同じように、Cisco Unified CallManager のダイヤル プランによる制御対象となります。ただし、Cisco Unified CallManager の番号分析は完全なダイヤル ストリングを使用して行われます（ユーザが入力したすべての桁が、1 つのブロックとして Cisco Unified CallManager に渡されて処理されます）。この動作モードでは、番号ストリングのダイヤル中のユーザ フィードバックは、電話機が提供できるものだけに制限されます（「SIP ダイヤル規則」を参照）。ストリングが合成された後も、Cisco Unified CallManager はユーザ フィードバックとしてコールプログレストーンを提供できます。

オンネットとオフネットのダイヤリング

同じテレフォニー ネットワーク上で発信され、終端するコールは、オンネットワーク（オンネット）と見なされます。これとは逆に、A 社で発信され、B 社で終端するコールは、通常は最初に A 社のネットワーク、次に公衆網、最後に B 社のネットワークというように、複数のテレフォニー ネットワークを通じてルーティングする必要があります。発信者から見ると、コールはオフネットワーク（オフネット）でルーティングされています。着信側から見ると、コールはオフネットで発生しています。

TDM システムでは、PBX または Centrex システムがテレフォニー システムのオンネット境界になります。TDM システムは、通常は 1 つのサイトの外側まで伸びていることはありません。伸びている場合も、その TDM システムは、大規模なシステム ハブの外周上に配置されていないサイトを含んでいないのが普通です。

IP テレフォニーの重要な特性の 1 つは、オンネットと見なすことのできるコール境界を拡張する機能です。たとえば、6 つの支店を保有している企業に所属するテレフォニー ユーザが、着信側が同じサイトにいる場合は省略ダイヤリング（4 桁の内線番号など）を使用して同僚に到達し、他のサイトにいる別の同僚に到達するときは、完全な公衆網番号をダイヤルしているとします。IP ベース システムを使用すると、すべてのユーザが同じ IP ネットワークによって処理されるため、6 つの支店を 4 桁の省略ダイヤリング プランによって経済的に結ぶことが可能になります。IP ネットワークを優先パスとして使用し、IP ネットワークが輻輳した場合のセカンダリ パスとして、公衆網への自動オーバーフローを使用します。

省略ダイヤリング

公衆網から直接到達可能な、ダイヤルイン（DID）機能を使用した内線番号があるとします。オフネットの公衆網発信者が DID 内線番号に到達するには、完全修飾公衆網番号（たとえば、1 415 555 1234）をダイヤルする必要があります。しかし、オンネットの発信者については、DID 番号の最後のいくつかの桁をダイヤルするだけでこの内線番号に到達する機能を利用することを考えています。4 桁の省略ダイヤル プランを使用すると、この例のオンネットの発信者は、1234 のみダイヤルすればこの内線番号に到達します。

内線ダイヤリングの重複の防止

テレフォニー システムは、どの内線番号にも明確な方法で到達できるように設定する必要があります。この目標を達成するには、ダイヤル プランが次の要件を満たす必要があります。

• すべてのオンネット内線ダイヤリングを、グローバルに一意なものにする。たとえば、4 桁の省略オンネット ダイヤル プランを使用するシステムで、サイト A とサイト B のどちらの内線番号についても、サイト C から 4 桁のみダイヤルして到達することが要件である場合、サイト A に内線番号 1000 があり、サイト B の別の内線番号も 1000 である状態は許されません。

• 個々のダイヤルストリングは、部分的にも重複していない。

–たとえば、4 桁の省略ダイヤル プランにおいて、9 をオフネット アクセス コードとして使用する場合（公衆網コールを発信する場合など）、内線番号を 9XXX にすることはできません。このように設定すると、コールがすぐにはルーティングされない状況が発生します。たとえば、ユーザが 9141 をダイヤルしたとします。システムは、追加の数字が入力されるか（ユーザが 9 1 415 555 1234 をダイヤルしようとしている場合など）、桁間タイムアウトに達するまで待機し、その後でコールを内線番号 9141 にルーティングします。同様に、オペレータ コード（たとえば 0）を使用する場合にも、0XXX の内線番号範囲全体を 4 桁の定型ダイヤル プランから除外する必要があります。

–長さが異なっていても、ストリングが重複していることは許されません。たとえば、システムで内線番号 1000 と 10000 を使用すると、1000 にダイヤルする場合、ユーザは桁間タイムアウトに達するまで待機する必要があります。

ダイヤリング ストリングの長さ

内線番号にダイヤルするときの必要桁数は、ダイヤル可能な内線番号の数によって決まります。たとえば、4 桁の省略ダイヤル プランでは、内線番号が 10,000 個（0000 ～ 9999）を超える場合には対応できません。0 と 9 をオペレータ コードおよびオフネット アクセス コードとしてそれぞれ予約する場合、この番号範囲は、さらに 8,000 個（1000 ～ 8999）まで減ります。

定型オンネット ダイヤル プラン

ダイヤル プランは、システム内のすべての内線番号に一定の方法で到達するように設計できます。つまり、任意のオンネット発信地点から、特定の内線番号に一定の桁数で到達することができます。ユーザにとって簡潔であるため、定型ダイヤリングを使用することをお勧めします。各種のオンネット ロケーションから発信するときに、番号をダイヤルするための方法をユーザがいくつも覚えておく必要がありません。

たとえば、任意のオンネット ロケーションから 1234 をダイヤルすると電話 A に到達するとします。この場合、発信側の電話が同じオフィスまたは別のサイトのどちらにあっても、企業のダイヤル プランは定型と見なすことができます。

企業のサイト数が少ない場合は、このアプローチを容易に採用できます。企業の内線番号とサイトの数が多くなるほど、定型ダイヤル プランを設計するときに次の点が問題になってきます。

• 内線番号の数は、ダイヤル プラン用に予定した桁数で対応できる範囲を超える場合もあります。たとえば、8,000 個（内線番号 0XXX と 9XXX を除外するものと想定）を超える内線番号が必要になった場合は、5 桁以上使用する省略ダイヤル プランが必要になります。

• オンネット省略内線番号を DID 番号と同じものにする場合、地域通信事業者から新しい DID 範囲を取得するときに、その範囲が既存のオンネット省略ダイヤルの範囲と競合することが許されなくなります。たとえば、4 桁の定型省略ダイヤル プランを使用しているシステムに、DID 範囲 415 555 1XXX があるとします。DID 範囲 650 556 1XXX の取得も検討している場合は、オンネット ダイヤリングの桁数を 5 に増やすことが望ましくなります。この例では、5 桁のオンネット範囲 51XXX と 61XXX は重複することがありません。

• ほとんどのシステムでは、一定の範囲をオフネット アクセス コードとオペレータ ダイヤリング用に除外する必要があります。9 と 0 が予約コードになっているシステムで、9 または 0 で始まるオンネット内線番号ダイヤリングに対応できるダイヤル プランは、（定型もそれ以外も）存在しません。つまり、ダイヤル プランで最初の数字として 9 または 0 を使用する必要がある場合は、最初の数字が 9 または 0 である DID 範囲を使用できません。たとえば、5 桁の省略ダイヤル プランを使用する場合、DID 範囲 415 559 XXXX（およびこのサブセット）は使用できません。この例では、代替策として、省略ダイヤリングの長さを 6 桁以上に増やすか、末尾の 5 桁が 9 で始まる DID 範囲を使用しないようにするという方法があります。

桁数を選定し、必要な範囲（たとえば、9 または 0 で始まる範囲）を除外したら、残りのダイヤリング スペースをすべてのサイトに分配する必要があります。

ほとんどのシステムでは、2 つの範囲を除外する必要があります。このため、ダイヤル範囲の先頭となる可能性が残っている数字は、8 つです。 表10-1 では、一般的な 4 桁の定型ダイヤル プランにおける、ダイヤリング スペースの分配例を示しています。

表10-1 の例では、さまざまなサイトが次の方法に従って番号を割り当てられています。

• サイト A（企業の本社）では、必要な内線番号が 1,000 個を超えるため、2 つの番号範囲（1XXX と 5XXX）全体を確保しています。対応する DID 範囲も、このサイトの地域通信事業者から取得する必要があります。

• サイト B は、1 つの範囲全体（2XXX）を割り当てられているため、内線番号を 1,000 個まで使用できます。

• サイト C も 1 つの範囲全体を割り当てられていますが、100 個の DID 内線番号（415 555 30XX）と 900 個の DID 以外の内線番号に分割されています。DID 内線番号がさらに必要になった場合は、DID 以外の範囲にある、まだ割り当てられていない番号を使用することができます。

• サイト D と E は、4XXX 範囲からそれぞれ 500 個ずつ番号を割り当てられています。対応する DID 範囲は、それぞれのサイトの 4XXX 範囲の部分と一致している必要があります。DID 範囲がサイトごとに異なっているため（おそらく、別の公衆網サービス プロバイダーから取得したことが原因）、サイト間で範囲を分割するには、密接な連携作業が必要です。特定の範囲内で割り当てられるサイトの数が多くなるほど、範囲全体をすべて使用することは困難になり、場合によっては不可能になります。

• サイト F の範囲は、900 個の DID 番号（6[0-8]XX）と 100 個の DID 以外の番号（69XX）に分割されています。

• 範囲 7XXX と 8XXX は、将来の使用に備えて予約されています。

新しいダイヤル プランを実装する場合、プラン立案者の主な目標の 1 つは、電話番号の変更が必要になるのを避けることです。また、既存の電話システムで内線番号範囲が重複している場合、過去に問題がなくても、定型ダイヤル プランでは許容されない場合があります。

可変長のオンネット ダイヤル プラン

サイトの数が多いシステムや、サイトの内線番号範囲が重複しているシステムでは、次の特性を備えた可変長ダイヤル プランを使用すると効果的です。

• サイトの内部では、オンネット内線番号へのコールに対して、省略ダイヤリング（4 桁の内線番号など）を引き続き使用できる。

• サイト間では、ユーザはアクセス コードをダイヤルし、次にサイト コードと宛先のオンネット内線番号をダイヤルする。

• オフネット コールの場合は、アクセス コードの次に公衆網番号をダイヤルする必要がある。

アクセス コードとダイヤル コードを使用すると（ 表10-2 を参照）、定型省略ダイヤル プランであれば重複となる内線番号を、オンネット ダイヤル プランで区別できるようになります。

表10-2 では、サイト A、B、C はそれぞれ独自に 4 桁範囲 1XXX を割り当てられています。従来のテレフォニー システムでは、サイト A からサイト B へのコールはオフネット コールとしてルーティングする必要がありました。新しいシステムでは、これらのコールをオンネット コールとしてダイヤルできます。

サイト A からは、ユーザは 1234 をダイヤルするだけで内線番号 1234 に到達できます。一方で、サイト B からサイト A の内線番号 1234 に対して、サイト B にある内線番号 1234 と競合することなく到達するには、ダイヤル プラン側で対応する必要があります。このため、各サイトにサイト コードが割り当てられています。

サイト B から、単にサイト A のコードを目的の内線番号と組み合せてダイヤルすることだけでは不十分です。この場合、11234 はサイト B の内線番号 1123 と部分的に重複しているため、桁間タイムアウトの問題が発生します。代わりに、サイト間オンネット アクセス コードとして 8 を割り当てると、サイト B から 81234 をダイヤルしてサイト A の内線番号 1234 に到達できるようになります。

オンネットのオフサイト内線番号にダイヤルするために必要な桁数は、次の要素によって決まります。

• サイト間アクセス コードに使用する 1 桁

• サイト コードに使用する N 桁（N は、必要となるサイト コードの数に見合う数値。たとえば、システムに 13 のサイトがある場合、サイト コードには少なくとも 2 桁が必要）

• 宛先サイトのローカル ダイヤル プランで必要となる桁数

たとえば、システムに 75 のサイトがあり、各サイトが 4 桁の省略ダイヤリングを使用している場合は、8 + SS + XXXX という形式が必要になります。8 はオンネット アクセス コード、SS は 2 桁のサイト コード、XXXX は 4 桁の内線番号で、合計 7 桁です。

オンネットとオフネットのアクセス コード

ほとんどの企業のテレフォニー システムでは、オフネットの宛先にコールを振り分けるためのオフネット アクセス コード専用として、1 つの数字（たとえば 9）を割り当てることが一般的です。可変長のオンネット ダイヤル プランでは、他のサイトにあるオンネット内線番号宛てのコールをダイヤルするために、オンネット アクセス コードとして、振り分け用の数字（たとえば 8）がもう 1 つ必要です。これらの 2 つのアクセス コードをオペレータ アクセス コード（たとえば 0）とともに使用するので、ダイヤル ストリングの先頭の数字となる可能性のある 10 個の数字からは、3 つが暗黙的に除外されます。この制限事項は、次の両方の理由から、好ましいものとは言えません。

• ユーザは、オンネットとオフネットの違いを理解し、適切なアクセス コードを選択する必要がある。

• 3 つのダイヤリング範囲全体を除外することによって、著しい制約や、一部の割り当て済み内線番号範囲との競合が生じる恐れがある。たとえば、サイトですでに 8 で始まる省略ダイヤリング範囲を使用している場合、この数字をアクセス コードとして使用するには、変更作業が必要になります。

定型オフネット アクセス コード（たとえば 9）をすでにすべてのサイトで使用しているシステムでは、同じコードをオフネットとオンネットの両方のオフサイト宛先に使用することをお勧めします。このアプローチには、主に次の 2 つの暗黙的要件があります。

• 部分的な重複や待ちが発生することを避けるには、アクセス コードの後に続く桁数を一定にする必要がある。

• テレフォニー システムは、ダイヤルされるすべてのオンネット番号をオフネット番号として認識し、IP ネットワーク経由でルーティングできる必要がある。このタスクは、Cisco Unified CallManager クラスタが 1 つしかない小規模システムの場合は単純ですが、複数の Cisco Unified CallManager クラスタがある大規模システムでは複雑なものになります。

事前の計画

IP ベースのシステムを実装するときは、ユーザの普段の操作手順を変更する必要が生じる場合もあります。新しいシステムのプランニングでは、この実装をできる限りユーザから見えないようにすることが望ましいのですが、それぞれ別のテレフォニー システム上にあった複数のサイトの統合に対応するには、ダイヤリング手順の調整が必要になることもあります。たとえば、企業全体にわたる新しいグローバルなダイヤル プランに対応するには、ユーザが他のサイトにいる別のユーザに到達する方法、サイト内コールに使用している桁数、ときには内線番号までも変更することが必要な場合もあります。ユーザが何度もダイヤル プラン変更を経験することを避けるには、企業規模の拡大を見越しておくようにします。企業が成長すると、複数のダイヤリング リージョンへのサイトの追加、オンネット内線番号の必要数の増加、公衆網番号の再割り当て（たとえば、エリア コードの分割など）、他国への事業展開が発生する可能性があります。

SCCP 電話機でのユーザ入力

SCCP を使用する IP Phone は、すべてのユーザ入力イベントをただちに Cisco Unified CallManager に報告します。たとえば、ユーザがオフフックにするとすぐに、その電話機が登録されている Cisco Unified CallManager サーバに電話機からシグナリング メッセージが送信されます。電話機は 1 つの端末と考えることができ、Cisco Unified CallManager サーバに設定されたダイヤル プランによって、ユーザ入力に起因するすべての決定がその端末で下されます。

その他のユーザ イベントが電話機で検出されると、そのイベントは個別に Cisco Unified CallManager にリレーされます。オフフックして 1000 をダイヤルしたユーザは、電話機から Cisco Unified CallManager に 5 つの独立したシグナリング イベントをトリガすることになります。その結果としてユーザに提供されるフィードバック、たとえば画面メッセージ、ダイヤル トーンの再生、2 次ダイヤル トーン、リングバック、リオーダーなどは、Cisco Unified CallManager がダイヤル プラン設定に基づいて電話機へ発行するコマンドです（図10-1 を参照）。

図10-1 SCCP 電話機でのユーザ入力とフィードバック

SCCP を実行する IP Phone 上にダイヤル プラン情報を設定する必要はなく、また設定できません。ダイヤル プラン機能は、ユーザ入力が収集されたときのダイヤリング パターンの認識も含めて、すべて Cisco Unified CallManager クラスタに含まれています。

ユーザのダイヤルしたパターンが Cisco Unified CallManager に拒否された場合は、そのパターンが Cisco Unified CallManager の番号分析でベストマッチになるとすぐに、そのユーザに対してリオーダー トーンが再生されます。たとえば、1 分刻みで課金される番号計画エリア（または市外局番）976 へのコールがすべて拒否される場合は、ユーザが 91976 をダイヤルするとすぐに、そのユーザの電話機にリオーダー トーンが送信されます。

タイプ A の SIP 電話機でのユーザ入力

この章では説明のため、タイプ A 電話機として Cisco Unified IP Phone 7905、7912、7940、および 7960 を定義します。タイプ A 電話機はタイプ B 電話機と動作が少し異なり、タイプ B 電話機では Keypad Markup Language（KPML）がサポートされていますが、タイプ A 電話機ではサポートされません（「タイプ B の SIP 電話機でのユーザ入力」を参照）。

SIP を使用するタイプ A の IP Phone には、次の 2 つの異なる動作モードがあります。

• 「電話機に SIP ダイヤル規則が設定されていない場合」

• 「電話機に SIP ダイヤル規則が設定されている場合」

電話機に SIP ダイヤル規則が設定されていない場合

図10-2 は、電話機にダイヤル プラン規則が設定されていない SIP タイプ A 電話機の動作を表しています。このモードでは、電話機はユーザが # キーを押すか Dial ソフトキーを押すまで、すべてのユーザ入力イベントを蓄積します。この機能は、多くの携帯電話で使用されている「送信」ボタンによく似ています。たとえば、内線 1000 にコールするユーザは、1、0、0、0 を押した後に Dial ソフトキーまたは # キーを押す必要があります。その後、電話機は Cisco Unified CallManager に SIP INVITE メッセージを送信し、内線 1000 へのコールの要求を示します。コールが Cisco Unified CallManager に到達すると、その電話機のダイヤル プラン設定に従います。その設定には、Cisco Unified CallManager のダイヤル プランに実装されているすべてのサービス クラスおよびコール ルーティング ロジックが含まれます。

図10-2 ダイヤル規則が設定されていないタイプ A の SIP 電話機でのユーザ入力とフィードバック

ユーザが番号をダイヤルした後に Dial ソフトキーや # キーを押さなかった場合、電話機は桁間タイムアウト（デフォルトでは 10 秒）だけ待ってから、SIP INVITE メッセージを Cisco Unified CallManager に送信します。図10-2 の例では、1、0、0、0 をダイヤルして桁間タイムアウトの時間だけ待つと、電話機は 10 秒後に内線 1000 にコールをつなぎます。

（注） ユーザが Redial ソフトキーを押した場合は、ただちに処理が行われるため、ユーザは Dial キーを押したり、桁間タイムアウトを待ったりする必要がありません。

ユーザが Cisco Unified CallManager に拒否されるパターンをダイヤルした場合、そのユーザはパターン全体を入力して Dial キーを押し、INVITE メッセージを Cisco Unified CallManager に送信した後でなければ、コールが拒否されたという通知（リオーダー トーン）は発信元に送信されません。たとえば、NPA 976 へのコールが拒否される場合は、919765551234 をダイヤルして Dial を押してから、リオーダー トーンが再生されます。

電話機に SIP ダイヤル規則が設定されている場合

SIP ダイヤル規則を使用すると、ユーザがダイヤルしたパターンを電話機が認識できます。認識作業が完了すると、SIP INVITE メッセージが Cisco Unified CallManager に自動的に送信され、ユーザは Dial キーを押したり、桁間タイムアウトを待ったりする必要がありません（詳細については、「SIP ダイヤル規則」を参照してください）。

たとえば、企業の支店で同一支店内の電話機間のコールに 4 桁の内線番号をダイヤルする必要がある場合は、4 桁のパターンを認識するように電話機を設定すれば、ユーザが Dial キーを押したり、桁間タイムアウトを待ったりする必要がありません（図10-3 を参照）。

図10-3 ダイヤル規則が設定されているタイプ A の SIP 電話機でのユーザ入力とフィードバック

図10-3 で、電話機は 1 で始まる 4 桁のパターンをすべて認識するように設定され、それに対応するタイムアウト値が 0 に設定されています。このパターンと一致するすべてのユーザ入力操作によって、SIP INVITE メッセージがすぐに Cisco Unified CallManager に送信され、ユーザが Dial キーを押す必要はありません。

SIP ダイヤル規則を使用するタイプ A 電話機では、電話機上に明示的に設定されていないパターンをダイヤルすることもできます。ダイヤルしたパターンが SIP ダイヤル規則と一致しない場合、ユーザは Dial キーを押すか、桁間タイムアウトを待ちます。

特定のパターンが電話機で認識され、それが Cisco Unified CallManager によってブロックされる場合、ユーザがダイヤル ストリング全体をダイヤルした後でなければ、コールがシステムで拒否されたという通知を受け取ることができません。たとえば、電話機に 919765551234 という形式でダイヤルされたコールを認識するように SIP ダイヤル規則が設定され、そのコールが Cisco Unified CallManager ダイヤル プランによってブロックされる場合、ユーザはダイヤリングの終了時（最後の 4 のキーを押した後）にリオーダー トーンを受信します。

タイプ B の SIP 電話機でのユーザ入力

この章では説明のため、タイプ B 電話機として Cisco Unified IP Phone 7911、7941、7961、7970、および 7971 を定義します。タイプ B 電話機はタイプ A 電話機と動作が少し異なり、タイプ B 電話機では Keypad Markup Language（KPML）がサポートされていますが、タイプ A 電話機ではサポートされません（「タイプ A の SIP 電話機でのユーザ入力」を参照）。

SIP を実行するタイプ B の IP Phone（Cisco Unified IP Phone 7911、7941、7961、7970、7971 など）には、次の 2 つの異なる動作モードがあります。

• 「電話機に SIP ダイヤル規則が設定されていない場合」

• 「電話機に SIP ダイヤル規則が設定されている場合」

電話機に SIP ダイヤル規則が設定されていない場合

タイプ B の IP Phone は、Keypad Markup Language（KPML）に基づいて、ユーザによるキー操作を報告する機能を提供します。ユーザ入力イベントの 1 つ 1 つにより、Cisco Unified CallManager に対して KPML をベースとした独自のメッセージが生成されます。ユーザの個々の操作をすぐに Cisco Unified CallManager にリレーするという点では、この操作モードは SCCP を実行している電話機の操作モードと非常によく似ています（図10-4 を参照）。

図10-4 ダイヤル規則が設定されていないタイプ B の SIP 電話機でのユーザ入力とフィードバック

ユーザのすべてのキー操作によって、Cisco Unified CallManager に対する SIP NOTIFY メッセージがトリガされることで、ユーザが押したキーに対応する KPML イベントが報告されます。このメッセージ機能により、Cisco Unified CallManager の番号分析はユーザが合成する部分パターンをその都度認識し、無効な番号がダイヤルされるとすぐにリオーダー トーンを再生するなど、適切なフィードバックを提供することができます。

ダイヤル規則なしに SIP を実行しているタイプ A の IP Phone とは異なり、タイプ B の SIP 電話機には、ユーザ入力の終わりを示す Dial キーがありません。図10-4 では、1000 をダイヤルするユーザは、最後の 0 をダイヤルした後、Dial キーを押さなくても、コールプログレストーン（リングバック トーンかリオーダー トーン）を受け取ります。この動作は、SCCP プロトコルを実行する電話機のユーザ インターフェイスとの整合性がとれています。

電話機に SIP ダイヤル規則が設定されている場合

タイプ B の IP Phone では、ダイヤルされたパターンの認識が電話機によって行われるように SIP ダイヤル規則を設定できます（図10-5 を参照）。

図10-5 ダイヤル規則が設定されているタイプ B の SIP 電話機でのユーザ入力とフィードバック

図10-5 で、電話機は 1 で始まる 4 桁のパターンをすべて認識するように設定され、それに対応するタイムアウト値が 0 に設定されています。このパターンと一致するすべてのユーザ入力操作によって、Cisco Unified CallManager への SIP INVITE メッセージの送信がトリガされます。

（注） SIP ダイヤル規則がタイプ B の IP Phone に実装されるとすぐに、KPML ベースのダイヤリングは無効になります。ユーザが SIP ダイヤル規則と一致しない番号ストリングをダイヤルした場合は、個々の桁のイベントが、どれも Cisco Unified CallManager にリレーされません。その代わり、ダイヤリングが完了すると（桁間タイムアウトの発生後）、ダイヤルされた番号全体が Cisco Unified CallManager にまとめて送信されます。

SIP ダイヤル規則を使用するタイプ B 電話機では、電話機上に明示的に設定されていないパターンをダイヤルする方法は 1 つだけです。ダイヤルされたパターンが SIP ダイヤル規則と一致しない場合、ユーザは桁間タイムアウトを待った後でなければ、Cisco Unified CallManager に SIP NOTIFY メッセージが送信されません。タイプ A の IP Phone とは異なり、タイプ B の IP Phone にはオンフック ダイヤルを使用した場合を除いて、ダイヤリングの終わりを示す Dial キーがありません。その場合、ユーザはいつでも「Dial」キーを押すことで、ダイヤルしたすべての桁の Cisco Unified CallManager への送信をトリガできます。

（注） タイプ B 電話機を SRST ルータに登録した場合、設定した SIP ダイヤル規則は無効になります。

特定のパターンが電話機で認識され、それが Cisco Unified CallManager によってブロックされる場合、ユーザがダイヤル ストリング全体をダイヤルした後でなければ、コールがシステムで拒否されたという通知を受け取ることができません。たとえば、電話機に 919765551234 という形式でダイヤルされたコールを認識するように SIP ダイヤル規則が設定され、そのコールが Cisco Unified CallManager ダイヤル プランによってブロックされる場合、ユーザはダイヤリングの終了時（4 のキーを押した後）にリオーダー トーンを受信します。

SIP ダイヤル規則

Cisco Unified CallManager には、ユーザ入力が収集されたときに電話機でパターン認識を実行できるように、SIP ダイヤル規則機能が備わっています。たとえば、誰もが知る 911 というパターンを認識したら Cisco Unified CallManager にメッセージを送信し、すぐに緊急コールが開始されるように電話機を設定できます。それと同時に、ユーザが国際電話番号の可変長のパターンを入力できるようにも設定できます。

注意すべき重要な点は、SIP ダイヤル規則を使用して電話機にパターン認識を設定しても、Cisco Unified CallManager のサービス クラスとルート プランの設定の方が優先されることです。ある電話機が長距離通話のパターンを認識するように設定されていても、その電話機がローカル コールのみを許可するサービスクラスに割り当てられていると、Cisco Unified CallManager がそのコールをブロックします。

SIP ダイヤル規則には、それらの規則を設定する電話機のモデルに基づいて、次の 2 つのタイプがあります。

• 7905_7912（Cisco Unified IP Phone 7905 および 7912 に使用）

• 7940_7960_OTHER（上記以外のすべての IP Phone モデルに使用）

ダイヤル規則の一部として使用できる基本的なダイヤル パラメータは、次の 4 つです。

• Pattern

このパラメータは、パターンの実際の数値表現です。数字、ワイルドカード、2 次ダイヤル トーンを再生する命令を含めることができます。次の表は、2 つのタイプのダイヤル規則について、値とその効果を示しています。

• IButton

このパラメータは、ダイヤル パターンの適用対象となるボタンを指定します。ユーザが回線ボタン 1 でコールを開始しようとしている場合は、ボタン 1 用に指定されたダイヤル パターンのみが適用されます。このオプション パラメータを設定しなかった場合、ダイヤル パターンは電話機のすべての回線に適用されます。このパラメータは、Cisco SIP IP Phone モデル 7940、7941、7960、7961、7970、および 7971 のみに適用されます。ボタン番号は、画面横にあるボタンの上から下の順に対応し、一番上のボタンが 1 になります。

• Timeout

このパラメータは、システムがタイムアウトになり、ユーザが入力した番号にダイヤルするまでの時間を秒単位で指定します。ダイヤルされた番号がすぐにダイヤルされるようにするには、0 を指定します。7940_7960_OTHER ダイヤル規則にのみ適用されます。このパラメータを省略した場合は、電話機のデフォルトの桁間タイムアウト値（デフォルトは 10 秒）が使用されます。

• User

このパラメータは、ダイヤルされた番号に自動的に追加されるタグを表します。有効な値は、 IP （Cisco Unified CallManager 以外の SIP コール エージェントが配置される場合）と Phone です。7940_7960_OTHER ダイヤル規則にのみ適用されます。このパラメータはオプションであり、Cisco Unified CallManager が唯一のコール エージェントとなる配置では省略してください。

（注） Cisco Unified IP Phone 7905 および 7912 は、パターンを SIP ダイヤル規則内で作成された順に選択します。これに対し、その他の電話機モデルでは、最長一致のパターンが選択されます。次の表は、ユーザが 95551212 をダイヤルした場合に選択されるパターンを示しています。

Cisco Unified CallManager におけるコール ルーティング

Cisco Unified CallManager 内に設定されるダイヤリング宛先は、すべて内部のコール ルーティング テーブルにパターンとして追加されます。このような宛先としては、IP Phone 回線、ボイスメール ポート、ルート パターン、トランスレーション パターン、および CTI ルート ポイントがあります。

番号がダイヤルされると、Cisco Unified CallManager は closest-match ロジックを使用し、コール ルーティング テーブルにあるすべてのパターンの中から一致パターンを選択します。一致している可能性のあるパターンが複数ある場合は、次の基準に基づいて宛先パターンを選択します。

• ダイヤルされたストリングに一致するもの。

• ポテンシャルマッチパターンのうち、ダイヤルされたストリング以外にマッチするパターンが最も少ないもの。

たとえば、図10-6 の場合を考えます。ここでは、コール ルーティング テーブルにパターン 1XXX、12XX、および 1234 が保持されています。

図10-6 Cisco Unified CallManager のコール ルーティング ロジックの例

ユーザ A がストリング 1200 をダイヤルすると、Cisco Unified CallManager は、この番号をコール ルーティング テーブル内のパターンと比較します。この場合は、一致する可能性のあるパターンが 2 つあります（1XXX と 12XX）。両方ともダイヤル ストリングに一致していますが、1XXX は合計 1,000 個のストリングに一致する一方で（1000 ～ 1999）、12XX は 100 個のストリングに一致します（1200 ～ 1299）。したがって、12XX がこのコールの宛先として選択されます。

ユーザ B がストリング 1212 をダイヤルした場合、一致する可能性のあるパターンは 3 つあります。上で説明したように、1XXX に一致するストリングは 1,000 個あり、12XX に一致するストリングは 100 個あります。しかし、121X に一致するストリングは 10 個しかありません。したがって、このパターンがコールの宛先として選択されます。

ユーザ C がストリング 1234 をダイヤルした場合、一致する可能性のあるパターンは 3 つあります（1XXX、12XX、1234）。上で説明したように、1XXX に一致するストリングは 1,000 個あり、12XX に一致するストリングは 100 個あります。しかし、1234 に一致するストリングは 1 個しかありません（ダイヤルされたストリング）。したがって、このパターンがコールの宛先として選択されます。

（注） Cisco Unified CallManager Release 4.0 以降でディレクトリ番号（DN）を設定すると、それぞれのデバイス（IP Phone など）が登録済みかどうかにかかわらず、その番号はコール ルーティング テーブルに配置されます。この動作は、これより前の Cisco Unified CallManager バージョンとは異なります。旧バージョンでは、パターンがコール ルーティング テーブルに追加されるのは、それぞれのデバイスが登録済みの場合のみでした。この仕様変更によって、アプリケーション（およびそのプライマリ パターン）が未登録である場合、セカンダリの一致パターンを利用してフェールオーバー機能を提供することができなくなりました。プライマリ パターンがコール ルーティング テーブルに必ず存在するため、セカンダリ パターンに一致するかどうかは検索されません。ただし、CTI ルート ポイントなどのプライマリ パターンの Forward Busy フィールドを使用して、フェールオーバーと同じ効果を得ることは可能です。Cisco Unified CallManager Release 4.0 以降では、このフィールドでワイルドカードを使用できるためです。

Cisco Unified CallManager は、同じクラスタ内の宛先にコールをルーティングする方法を自動的に「習得」します。公衆網ゲートウェイ、H.323 ゲートキーパー、またはその他の Cisco Unified CallManager クラスタなどの外部宛先の場合、外部ルート コンストラクト（次の項で説明）を使用して、明示的にルーティングを設定する必要があります。このコンストラクトは、3 層式のアーキテクチャに基づいています。このアーキテクチャでは、複数層のコール ルーティングと共に、番号操作も可能です。Cisco Unified CallManager は、外部ダイヤル ストリングと一致する設定済みルート パターンを検索し、それを使用して、対応するルート リストを選択します。ルート リストには、コールに使用可能なパスが優先順位順に並べられています。これらのパスは、ルート グループと呼ばれ、従来の PBX でトランク グループと呼ばれていたものに非常によく似ています。図10-7 では、Cisco Unified CallManager 外部ルート コンストラクトの 3 層式アーキテクチャを示しています。

図10-7 外部ルート パターンのアーキテクチャ

次の各項では、Cisco Unified CallManager の外部ルート コンストラクトの個々の要素について説明します。

• 「ルート パターン」

• 「ルート リスト」

• 「ルート グループ」

• 「ルート グループ デバイス」

ルート パターン

ルート パターンは、コールを外部エンティティにルーティングするために Cisco Unified CallManager で設定された、数字とワイルドカードを組み合せたストリング（たとえば、9.[2-9]XXXXXX）です。ルート パターンでは、コールをルーティングするゲートウェイを直接指すことも、ルート リストを指すこともできます。ルート リストはルート グループを指しており、最終的にゲートウェイを指します。

ルート パターン、ルート リスト、およびルート グループ コンストラクトとを完全パスで指定するようにシスコは強くお勧めします。その理由は、この構造を使用するとコール ルーティング、番号操作、および将来のダイヤル プランの拡張を最も柔軟に行うことができるからです。

@ ワイルドカード

• @ ワイルドカードは、特殊なマクロ関数であり、特定の国の番号計画全体を表す一連のパターンに拡張されます。たとえば、フィルタ処理されていない単一のルート パターン（たとえば、9.@）を北米番号計画を使用して設定すると、実際には、Cisco Unified CallManager の内部ダイヤル プラン データベースに 166 個の個別ルート パターンが追加されます。

• その他の国別番号計画を受け入れるように Cisco Unified CallManager を設定できます。この作業が完了すると、Route Pattern 設定ページの Numbering Plan フィールドで選択した値に応じて、同じ Cisco Unified CallManager クラスタ内で、複数の番号計画に対して @ ワイルドカードを使用できるようになります。詳細については、次の Web サイトで入手可能な『 Cisco Unified CallManager Dial Plan Deployment Guide 』を参照してください。

http://www.cisco.com/en/US/products/sw/voicesw/ps5629/prod_maintenance_guides_list.html

• @ ワイルドカードは、いくつかの中小規模の配置では十分に実務で使用できますが、大規模な配置では、管理とトラブルシューティングが困難になる可能性があります。これは、@ ワイルドカードを利用する場合、ルート フィルタを使用して、管理者が特定のパターンをブロックする必要があるためです（「ルート フィルタ」を参照してください）。

ルート フィルタ

• ルート フィルタは、@ ワイルドカードによって作成されるルート パターン数を減らすために、@ ルート パターンと一緒にのみ使用します。

• ルート フィルタと一緒に入力する論理式は、NOT-SELECTED フィールドを除いて、最大 1024 文字にすることができます。

• ルート フィルタ内の論理文節数が増えるにつれて、設定ページのリフレッシュ時間も増え、容認できないほど長くなる場合があります。

• 大規模な配置の場合、@ ワイルドカードとルート フィルタではなく、明示ルート パターンを使用してください。この方法を利用すると、管理とトラブルシューティングも容易になります。これは、Cisco Unified CallManager で設定されているすべてのパターンが、Route Pattern 設定ページから簡単に参照できるからです。

国際および可変長ルート パターン

• 国際間の宛先は、通常、任意の桁数を表す ! ワイルドカードを使用して設定されます。たとえば、北米では通常、国際コール用にルート パターン 9.011! が設定されています。欧州諸国のほとんどでは、0.00! ルート パターンを使用することで同じ結果が得られます。

• ! ワイルドカードは、ダイヤルされる番号の長さが変化する国では配置にも使用されます。このような場合、Cisco Unified CallManager は、ダイヤルがいつ完了するかわからないので、コールの送信前に 15 秒待機します。この遅延は、次の方法のいずれかで短縮できます。

–ダイヤルの終わりを指定する T302 タイマー（サービス パラメータ TimerT302_msec）の値を減らします。ただし、ユーザがダイヤルを終了する前のコールの早期送信を防止するために、4 秒以上に設定します。

–# ワイルドカードで終了する同じパターンのルートパターンを設定し（たとえば、北米の場合 9.011!#、欧州の場合 0.00!#）、ダイヤルの終わりを示すために # をダイヤルするようにユーザに指示します。この処置は、携帯電話で送信ボタンを押すことに相当します。

重複送信と重複受信

国内の番号計画をスタティック ルート パターンで定義することが難しい国では、Cisco Unified CallManager に重複送信および重複受信を設定することができます。

重複送信とは、エンドユーザのダイヤルする数字を Cisco Unified CallManager で収集しながら、数字がダイヤルされると同時に公衆網に渡すことを意味します。Cisco Unified CallManager Release 4.0 以降で重複送信を使用可能にするには、Route Pattern Configuration ページの Allow Overlap Sending チェックボックスをオンにします。これより前の Cisco Unified CallManager リリースで重複送信を使用可能にするには、SendingCompleteIndicator サービス パラメータを False に設定します。ルート パターンには、公衆網アクセス コード（たとえば、北米では 9、欧州諸国の多くでは 0）を含める場合のみです。

重複受信とは、ダイヤルされる数字を PRI 公衆網ゲートウェイから Cisco Unified CallManager で 1 つずつ受信し、ストリングのダイヤルが完了するまで待機し、その後でコールを内部宛先にルーティングすることを意味します。Cisco Unified CallManager Release 3.3(3) 以降で重複受信を使用可能にするには、OverlapReceivingFlagForPRI サービス パラメータを Trule に設定します。これより前の Cisco Unified CallManager リリースでは、パラメータ名は OverlapReceivingForPriFlag です。

ルート パターンにおける番号操作

• 番号操作は、ルート パターンではなく、ルート グループのみで設定してください。

• ルート グループでの番号操作は、ルート パターンで行われた番号操作を完全に上書きします。

• ルート パターンで番号操作を設定する場合、コール詳細レコード（CDR）は、番号操作が行われた後のダイヤル番号を記録します。ルート グループだけで番号操作を設定する場合、CDR は、番号操作が行われる前の実際のダイヤル番号を記録します。

• 同様に、ルート パターンでの番号操作を設定すると、発信側の IP Phone ディスプレイおよび Placed Calls レジスタには、操作後の番号が示されます。ルート グループのみで番号操作を設定する場合、この操作はエンドユーザには見えなくなります。

発呼回線 ID

• 発呼回線 ID の表示は、ゲートウェイで使用可能または使用不可にすることができます。また、サイトの要件に基づいて、ルート パターンで操作することもできます。

• Use Calling Party's External Phone Number Mask オプションを選択する場合、外部コールは、コールを発信する IP Phone に指定された発呼回線 ID を使用します。このオプションを選択しない場合、Calling Party Transform Mask フィールドに指定されたマスクが、発信者番号識別の生成に使用されます。

緊急プライオリティ

• Urgent Priority チェックボックスは、一般に、パターンに一致したコールを T302 タイマーの満了を待たずにすぐルーティングする目的で使用されます。たとえば、北米でパターン 9.911 と 9.[2-9]XXXXXX が設定されている場合、ユーザが 9911 をダイヤルすると、Cisco Unified CallManager は T302 タイマーが満了するまで待機し、その後でコールをルーティングします。これは、9911 の後に数字が入力されて、9.[2-9]XXXXXX に一致する可能性があるためです。9.911 ルート パターンについて緊急プライオリティを有効にすると、Cisco Unified CallManager はユーザが 9911 とダイヤルした直後にルーティング処理を実行し、T302 タイマーの満了までは待機しません。

• Urgent Priority チェックボックスをオンにした場合に実行されるのは、設定済みのパターンがダイヤルされた番号とのベストマッチになったとき、その直後に T302 タイマーを満了させることです。つまり、緊急パターンが他のパターンよりも高い優先順位を持っているわけではありません。「Cisco Unified CallManager におけるコール ルーティング」の項で説明した closest-match ロジックは、依然として有効です。

たとえば、ルート パターン 1XX が緊急パターンとして設定され、パターン 12! が通常のルート パターンとして設定されているとします。ユーザが 123 とダイヤルした場合、Cisco Unified CallManager は 3 番目の数字を受信した直後にはルーティング処理を実行しません。1XX は緊急パターンであっても、ベストマッチではないからです（12! が合計 10 個のパターンに一致するのに対して、1XX は 100 個のパターンに一致）。パターン 12! では、ユーザがさらに番号を入力する可能性があるため、Cisco Unified CallManager は桁間タイムアウトを待ってから、コールをルーティングする必要があります。

別の例として、パターン 12[2-5] に緊急のマークが付けられ、12! が通常のパターンとして設定されている場合を考えてみます。ユーザが 123 とダイヤルすると、パターン 12[2-5] はベストマッチになります（12[2-5] が合計 4 個のパターンに一致するのに対し、12! は 10 個のパターンに一致）。緊急プライオリティ パターンがベストマッチなので、T302 タイマーは打ち切られ、それ以上のユーザ入力は想定されません。Cisco Unified CallManager は、パターン 12[2-5] を使用してコールをルーティングします。

コール分類

• このルート パターンを使用しているコールは、オンネットまたはオフネットのコールとして分類することができます。このルート パターンを使用すると、オフネット間でのコール転送を禁止したり、オンネット通話者がいないコンファレンス ブリッジを終了したりすることによって、料金詐欺を防止できます（これらの機能は、どちらも Cisco Unified CallManager Administration の Service Parameters を使用して制御します）。

• Allow device override チェックボックスをオンにすると、コールは、関連するゲートウェイまたはトランク上で、コール分類設定に基づいて分類されるようになります。

強制アカウント コード（FAC）

• Forced Account Codes（FAC）チェックボックスを使用すると、個々のルート パターンを使用して発信コールが制限されます。ルート パターンに対して FAC を有効にすると、ユーザは、目的のコール受信者に到達するための許可コードを入力するように要求されます。

• ユーザのダイヤルした番号が、FAC が有効になったルート パターンを通じてルーティングされるものである場合、システムは許可コードの入力を求めるトーンを再生します。コールを確立するには、ユーザ許可コードが、ダイヤルされた番号のルーティングに必要となる許可レベルにを満たしているか、そのレベルを超えている必要があります。

• コール詳細レコード（CDR）に表示されるのは、許可名のみです。許可コードは CDR には表示されません。

• FAC 機能は、Allow overlap sending チェックボックスがオンの場合は使用できません。

クライアント証明書コード（CMC）

• Client Matter Code（CMC）チェックボックスを使用すると、個々のルート パターンを使用して特定番号へのコールがトラッキングされます。たとえば、企業で使用すると、特定のクライアントへのコールをトラッキングできます。

• ルート パターンに対して CMC を有効にすると、ユーザは目的の宛先に到達するためのコードを入力するように要求されます。

• ユーザのダイヤルした番号が、CMC が有効になったルート パターンを通じてルーティングされるものである場合、システムはコードの入力を求めるトーンを再生します。コールを確立するには、ユーザが正しいコードを入力する必要があります。

• クライアント証明書コードは、コール詳細レコードに表示されます。これは、クライアントの課金およびアカウンティングに関するレポートを生成するための、CDR の分析およびレポート ツールで使用できるようにするためです。

• CMC 機能は、Allow overlap sending チェックボックスがオンの場合は使用できません。

• CMC と FAC を両方とも有効にすると、ユーザは番号をダイヤルするとき、FAC の入力を求められたら入力し、次のプロンプトで CMC を入力します。

ルート リスト

ルート リストは、発信コールに使用できるパス（ルート グループ）が優先順位順に並べられたリストです。一般に、1 つのルート リストは、1 つのリモート ロケーションに関連付けられ、複数のルート パターンがそのルート リストを指定することができます。ルート リストの標準的な用途は、リモートの宛先に 2 つのパスを指定することです。この場合、第一選択のパスは、IP WAN を介したパスであり、第二選択のパスは、ローカル公衆網ゲートウェイを介したパスです。

ルート リストには次の特性があります。

• 複数のルート パターンが同一ルート リストを指すことができます。

• ルート リストは、所定の宛先への代替パスの役目をするルート グループが、優先順位順に並べられたリストです。たとえば、ルート リストを使用して最低料金選択機能をサポートすることができます。この場合、リスト内のプライマリ ルート グループが、コール当たりのコストがより低くなるようにします。プライマリ ルート グループが「all trunks busy（全トランク使用中）」状態、または IP WAN リソースの不足により使用できない場合だけ、セカンダリ ルート グループが使用されます。

• ルート リスト内の各ルート グループは、独自の番号操作を行うことができます。たとえば、ルート パターンが 9.@ であるときに、ユーザが 91 408 555 4000 をダイヤルした場合、IP WAN ルート グループは 9 1 を削除し、公衆網ルート グループは 9 だけを削除することが可能です。

• 複数のルート リストに、同じルート グループを含むことができます。ルート グループの番号操作は、そのルート グループを指定する特定のルート リストに関連しています。

• ルート パターンまたはルート グループ内で複数の番号操作を実行しようとする場合、変換が実行される順序が、変換結果の E.164 アドレスに影響を与える可能性があります。Cisco Unified CallManager は、次に示す主要なタイプの番号操作を表示されている順に実行します。

1. 数字を破棄する

2. 着信番号変換

3. 数字をプレフィックスとして付加する

ルート グループ

ルート グループは、一般にゲートキーパーまたはリモート Cisco Unified CallManager クラスタとのゲートウェイ（MGCP または H.323）、H.323 トランク、または SIP プロキシへの SIP トランクである特定のデバイスを制御し、それを指定します（Cisco CallManager Release 3.2 以前では、H.323 トランクの役割は、「Anonymous Device」ゲートウェイ、および Intercluster Trunk プロトコルを使用して設定された H.323 ゲートウェイによって実行されていました）。

Cisco Unified CallManager は、割り当てられている分配アルゴリズムに従ってコールをデバイスに送信します。Cisco Unified CallManager では、トップダウン アルゴリズムと循環アルゴリズムをサポートしています。

ルート グループ デバイス

ルート グループ デバイスは、ルート グループによってアクセスされるエンドポイントであり、一般に、ゲートキーパーまたはリモート Cisco Unified CallManager とのゲートウェイまたは H.323 トランクで構成されます。次のタイプのデバイスは、Cisco Unified CallManager で設定できます。

• メディア ゲートウェイ コントロール プロトコル（MGCP）ゲートウェイ

• H.323 ゲートウェイ

• H.225 トランク、ゲートキーパー制御：ゲートキーパーを介した標準 H.323 ゲートウェイとのトランク

• クラスタ間トランク、非ゲートキーパー制御：別の Cisco Unified CallManager クラスタとの直接トランク

• クラスタ間トランク、ゲートキーパー制御：ゲートキーパーを介した他の Cisco Unified CallManager クラスタまたは H.323 ゲートウェイとのトランク

• SIP トランク：SIP プロキシへのトランク（Cisco Unified CallManager Release 4.0 以降で使用可能）

（注） H.225 トランクとクラスタ間トランク（ゲートキーパー制御）はどちらも、相手方エンドポイントが標準 H.323 ゲートウェイであるか、Cisco Unified CallManager であるかを自動的に検出し、それに応じて H.225 または Intercluster Trunk プロトコルを選択します

Cisco Unified CallManager におけるコール特権

ダイヤリング特権は、特定のエンドポイント（電話、ゲートウェイ、または CTI アプリケーションなど）にどのタイプのコールを許可する（または禁止する）かを制御するために設定されます。Cisco Unified CallManager で処理されるすべてのコールは、次の要素の設定で実装されたダイヤリング特権の対象になります。

• 「パーティション」

• 「コーリング サーチ スペース」

パーティションは、同じアクセス可能性を持つディレクトリ番号のグループです。コーリング サーチ スペースは、特定のデバイスからどのパーティションがアクセス可能であるかを指定します。デバイスは、コーリング サーチ スペースに含まれているパーティション内の DN だけを呼び出すことができます。

図10-8 に示すように、パーティション内に配置できるすべての項目は、ダイヤリングの対象となるパターンを持っています。このような項目としては、電話回線、ルート パターン、トランスレーション パターン、CTI ルート グループ回線、CTI ポート回線、ボイスメール ポート、および Meet-Me 会議番号があります。逆に、コーリング サーチ スペースを持つ項目は、コールをダイヤルできるすべてのデバイスです。たとえば、電話機、電話回線、ゲートウェイ、アプリケーション（CTI ルート グループまたはボイスメール ポート経由）などです。

図10-8 パーティションとコーリング サーチ スペース

パーティション

パーティションに含めることができるダイヤル プラン項目には、IP Phone のディレクトリ番号、トランスレーション パターン、ルート パターン、CTI ルート ポイント、およびボイスメール ポートがあります。「Cisco Unified CallManager におけるコール ルーティング」で説明するように、複数のダイヤル プラン項目（ディレクトリ番号、ルート パターンなど）が重複する場合、Cisco Unified CallManager は、ダイヤルされた番号と一致するか、または最も近い（最も固有性の高い一致）項目を選択します。2 つのダイヤル プラン項目が、ダイヤルされたパターンに等しく一致した場合、Cisco Unified CallManager は、コールを発信するデバイスのコーリング サーチ スペース内で最初に表示されているダイヤル プラン項目を選択します。

たとえば、図10-9 について考えます。ルート パターン 1XXX と 23XX はパーティション A の一部であり、ルート パターン 12XX と 23XX はパーティション B の一部です。発信デバイスのコーリング サーチ スペースには、パーティション A:パーティション B の順にパーティションがリストされています。このデバイスのユーザが 2345 をダイヤルすると、Cisco Unified CallManager は、パーティション A のルート パターン 23XX を一致項目として選択します。これは、このパターンが発信デバイスのコーリング サーチ スペースで最初に示されているためです。ただし、ユーザが 1234 をダイヤルした場合には、Cisco Unified CallManager はパーティション B のルート パターン 12XX を一致項目として選択します。これは、パーティション A の 1XXX よりも一致率が大きいためです。コーリング サーチ スペースに含まれているパーティションの順序は、closest-match ロジックに基づいて均等一致項目が複数あった場合に、競合を解消する要素としてのみ使用されます。

図10-9 マッチング ロジックにおけるパーティション順序の影響

（注） 均等一致項目が同じパーティションに複数ある場合、Cisco Unified CallManager は、ローカルのダイヤル プラン データベース内で最初にリストされている項目を選択します。ダイヤル プラン データベース内でダイヤル プラン項目がリストされる順序は、設定することができません。したがって、同じパーティション内で均等一致項目が共存しないようにすることを強くお勧めします。これはこのような場合に発生するダイヤル プラン ロジックが予測できないからです。

Cisco Unified CallManager Release 4.1 以降では、日時に基づいてパーティションをアクティブまたは非アクティブにすることができます。パーティションをアクティブまたは非アクティブにするには、まず、Cisco Unified CallManager Administration で期間とスケジュールを設定し、次に個々のタイム スケジュールを各パーティションに割り当てます。スケジュールに指定した日時の範囲外では、このパーティションは非アクティブになります。このパーティションに含まれているパターンは、Cisco Unified CallManager コール ルーティング エンジンによってすべて無視されます。この機能の詳細については、「時間帯ルーティング」を参照してください。

コーリング サーチ スペース

コーリング サーチ スペースは、特定のデバイスからどのパーティションがアクセス可能であるかを指定します。所定のコーリング サーチ スペースが割り当てられるデバイスは、そのコーリング サーチ スペースにリストされているパーティションだけにアクセスできます。そのコーリング サーチ スペース以外のパーティションの DN へのダイヤルは失敗します。発信者にはビジー信号が聞こえます。

IP Phone 回線とデバイス（電話機）自体の両方でコーリング サーチ スペースを設定する場合、Cisco Unified CallManager は、この 2 つのコーリング サーチ スペースを図10-10 に示すように連結し、デバイスのコーリング サーチ スペースの前に、回線のコーリング サーチ スペースを置きます。

図10-10 IP Phone の回線とデバイスのコーリング サーチ スペース（CCS）の連結

同じルート パターンが、2 つのパーティション（回線のコーリング サーチ スペースに含まれているパーティションとデバイスのコーリング サーチ スペースに含まれているパーティション）に指定されている場合、Cisco Unified CallManager は、「パーティション」の項で説明している規則に従って、パーティションの連結リスト内で最初にリストされているルート パターン（この場合、回線のコーリング サーチ スペースに関連したルート パターン）を選択します。

回線とデバイスのコーリング サーチ スペースを設定する方法に関する推奨事項については、「従来のアプローチによる Cisco Unified CallManager のサービス クラスの構築」と 「回線/デバイス アプローチによる Cisco Unified CallManager のサービス クラスの構築」の項を参照してください。

結合されたコーリング サーチ スペース（デバイスと回線）の最大長は、各パーティション名間の区切り文字を含めて、1024 文字です（たとえば、ストリング「partition_1:partition_2:partition_3」は 35 文字です）。したがって、コーリング サーチ スペース内の最大パーティション数は、パーティション名の長さに応じて変動します。また、コーリング サーチ スペースの文節は、デバイスのコーリング サーチ スペースと回線のコーリング サーチ スペースを結合するので、個々のコーリング サーチ スペースの最大文字の上限は、512 文字（結合されたコーリング サーチ スペース文節の上限 1024 文字の半分）です。

したがって、パーティションとコーリング サーチ スペースを作成するときは、コーリング サーチ スペースに含める予定のパーティション数を基準にして、パーティション名を短くしてください。コーリング サーチ スペースの設定の詳細は、次の Web サイトで入手可能なオンラインの『Cisco Unified CallManager Administration Guide』を参照してください。

http://www.cisco.com

パーティションまたはコーリング サーチ スペースを設定する前に、すべての DN は、<None> という名前が付いた特別なパーティションに置かれ、すべてのデバイスには、<None> という名前が付いたコーリング サーチ スペースが割り当てられます。カスタム パーティションとコーリング サーチ スペースを作成する場合は、作成するどのコーリング サーチ スペースにも、<None> パーティションが含まれています。一方、<None> コーリング サーチ スペースには、<None> パーティションだけが入っています。

（注） <None> パーティションに残っているどのダイヤル プラン項目も、コールを発信する任意のデバイスから暗黙的に到達可能です。したがって、予期しない結果を避けるために、<None> パーティションにダイヤル プラン項目を残さないように強くお勧めします。

（注） <None> と定義されたままのコーリング サーチ スペースを残さないでください。そのままにしておくと、ダイヤル プランの動作が予測困難になる可能性があります。

自動転送コーリング サーチ スペース

Release 5.0 以外のバージョンの Cisco Unified CallManager では、回線に対して設定されているメインのコーリング サーチ スペースは、デバイスのコーリング サーチ スペースと連結されます。一方、3 タイプの自動転送（Forward All、Forward Busy、Forward No Answer）に対して設定されているコーリング サーチ スペースは、他のどのコーリング サーチ スペースとも連結されないスタンドアロン値です。

Cisco Unified CallManager Release 5.0 では、Call Forward All コーリング サーチ スペースは Directory Number 設定ページにある Secondary Calling Search Space for Forward All に連結され、それで得られるコーリング サーチ スペースは、Forward All 動作が User ページまたは Administrative ページから開始された場合にすべてのコールに適用されます。

これらの連結されたコーリング サーチ スペースは、SCCP を実行している電話機または SIP を実行しているタイプ B の電話機から Forward All 動作が起動されたときにも使用されます。詳細については、「回線/デバイス アプローチによる Cisco Unified CallManager のサービス クラスの構築」を参照してください。

SIP を実行しているタイプ A の IP Phone では、Call Forward All がその電話機自体から起動された場合、転送されるコールにデバイスの Rerouting Calling Search Space が使用されます。Forward All 動作が CallManager User ページまたは CallManager Administrative ページから起動される場合、その電話機から開始される Forward All 動作とは無関係になります。

たとえば、SIP を実行するタイプ A の IP Phone に、CallManager User ページで内線 3000 への Forward All が指定されているとします。同時に、その電話機自体には、内線 2000 への Forward All が設定されています。この場合、その電話機に対するすべてのコールは、内線 3000 に転送されます。

（注） SIP を実行するタイプ A の IP Phone では、CallManager User ページまたは Administrative ページからの Forward All の起動は、電話機に反映されません。電話機には、コールの転送に関する確認は何も表示されません。

SCCP を実行する IP Phone または SIP を実行するタイプ B の IP Phone から Forward All が起動された場合、ユーザ入力は入力と同時に、設定済みの Forward All コーリング サーチ スペースの中で許可されるパターンと比較されます。無効な宛先パターンが設定されていると、ユーザにはリオーダー トーンが聞こえます。SIP を実行するタイプ A の IP Phone から Forward All が起動された場合、Forward All ユーザ入力は電話機上にローカルに保管され、Cisco Unified CallManager 内のコーリング サーチ スペースとは照合されません。ユーザ入力が無効な宛先に対応している場合でも、ユーザへの通知はありません。その電話機へのコールに対しては、電話機が無効な宛先番号に対して SIP 再ルーティング動作を開始しようとしたときに、リオーダー トーンが再生されます。

Forward All コーリング サーチ スペースが <None> のままになっている場合、処理の結果は Cisco Unified CallManager のリリースによって異なり、予想することは困難です。このため、自動転送のコーリング サーチ スペースを設定する場合は、次のベスト プラクティスに従うことをお勧めします。

• 自動転送コーリング サーチ スペースは、常に <None> 以外の値を使用して設定する。この設定により混乱を避けることができ、トラブルシューティングが容易になります。転送されるコールにどのコーリング サーチ スペースが使用されるかについて、ネットワーク管理者が正確に把握できるためです。

• Call Forward Busy コーリング サーチ スペースと Call Forward No Answer コーリング サーチ スペースは、ボイスメール パイロットおよびボイスメール ポートの DN に到達可能で、かつ外部公衆網番号以外の値を使用して設定する。

• Call Forward All コーリング サーチ スペースと Secondary Calling Search Space for Forward All は、どちらも企業のポリシーに従って設定する。多くの企業では、コールを社内の番号にしか転送できないように制限しています。この方法によって、ユーザが IP Phone の回線を長距離電話の番号に転送したり、私用電話の長距離通話料金がかからないようにするためにローカル IP Phone の番号に公衆網からダイヤルしたりすることを防止します。

Cisco Unified CallManager における番号操作

Cisco Unified CallManager の番号操作機能は、次のツールが提供しています。

• 外部ルート コンストラクト（ルート パターン、ルート リスト、ルート グループ）

• トランスレーション パターン

外部ルート コンストラクトを使用すると、コールを外部デバイスにルーティングしながら一部の番号操作を実行できます。この機能については、「Cisco Unified CallManager におけるコール ルーティング」の項で説明しています。

トランスレーション パターンは、Cisco Unified CallManager で最も強力な番号操作ツールであり、あらゆるタイプのコールに対して使用できます。トランスレーション パターンは、ルート パターンと同じ一般規則に従い、同じワイルドカードを使用します。ルート パターンと同じように、トランスレーション パターンをパーティションに割り当てます。しかし、ダイヤルされた数字がトランスレーション パターンと一致する場合、Cisco Unified CallManager は、ゲートウェイなどの外部エンティティにコールをルーティングしません。代わりに、まず変換を実行した後、トランスレーション パターン内で設定されたコーリング サーチ スペースを使用して、コールを再度ルーティングします。

トランスレーション パターンは、図10-11 の例に示すように、さまざまな用途に使用することができます。

図10-11 トランスレーション パターンの応用例

この例では、管理者は、0 をダイヤルすると到達できるオペレータ サービスをユーザに提供し、一方で定型の内部番号計画をそのまま維持することを考えています。IP Phone は、Translations_pt パーティションを（他のパーティションとともに）含んでいる Phone_css コーリング サーチ スペースを使用して設定されています。このパーティションには、トランスレーション パターン 0 が定義されています。設定済みの Called Party Transform Mask によって、ダイヤル ストリング（0）を新しいストリング 2001 で置き換えるように Cisco Unified CallManager に指示しています。2001 は、オペレータの電話の DN に対応しています。2 回目の（この場合は 2001 の）ルックアップが、Internal_css コーリング サーチ スペースを使用して、コール ルーティング エンジンを通じて強制的に実行されます。この時点で、AllPhones_pt パーティションに含まれている実際のオペレータ DN（2001）までコールを伸ばすことができます。

（注） ダイヤルされた番号をトランスレーション パターンを使用して操作すると、その変換後の番号が、コール詳細レコード（CDR）に記録されます。ただし、番号操作がルート リスト内で発生した場合、CDR には変換後の番号ではなく、ダイヤルされた元の番号が表示されます。IP Phone の Placed Calls ディレクトリには、常にユーザがダイヤルしたストリングがそのまま表示されます。

Automated Alternate Routing

自動代替ルーティング（AAR）機能を使用すると、Cisco Unified CallManager で音声メディア用の代替パスを確立することができます。このパスが確立されるのは、同じクラスタ内の 2 つのエンドポイント間にある優先パスで、コール アドミッション制御用のロケーション メカニズムによって決定される使用可能帯域幅が使い果たされたときです。

AAR 機能の主な適用対象は、集中型コール処理配置です。たとえば、支店 A の電話から支店 B の電話にコールする場合、支店間の WAN リンクで使用可能な帯域幅（ロケーション メカニズムによって計算）が不足しているときは、AAR によって公衆網経由でコールを再ルーティングできます。コールの音声パスは、発信元の電話からローカルの（支店 A の）公衆網ゲートウェイまでは IP ベース、このゲートウェイから公衆網を経由して支店 B のゲートウェイまでは TDM ベース、支店 B のゲートウェイから宛先の IP Phone までは IP ベースです。

AAR による処理は、ユーザには見えません。ユーザが着信側電話のオンネット（たとえば 4 桁の）ディレクトリ番号にしかダイヤルできないように AAR を設定すると、公衆網などの代替ネットワーク経由で宛先に到達するときに、ユーザによる追加入力が不要になります。

（注） AAR では、CTI ルート ポイントがコールの発信元や宛先になることはサポートしていません。また、ユーザが複数のサイトにわたってローミングする場合、AAR はエクステンション モビリティ機能と共存できません。詳細については、「エクステンション モビリティ」を参照してください。

AAR を正常に動作させるには、AAR の次の主要要素を指定する必要があります。

• 「宛先公衆網番号の確立」

• 「必要なアクセス コードの付加」

• 「適切なダイヤル プランおよびルートの選択」

（注） Cisco Unified CallManager Release 4.1.3 以降では、自動代替ルーティング（AAR）をボイスメール ハント グループのメンバーに適用することができます。

宛先公衆網番号の確立

コールを再ルーティングするには、公衆網などの代替ネットワーク経由でルーティングできる宛先ディレクトリ番号（DN）を使用する必要があります。AAR は、ダイヤルされた番号を使用してコールのクラスタ上での宛先を特定し、この番号を着信側の外部電話番号マスクと結合します。この 2 つの要素を結合することで、代替ネットワークによってルーティング可能な、完全修飾番号（Fully Qualified Number）が生成される必要があります。

たとえば、San Francisco にある電話 A（DN = 2345）から、New York の電話 B 上に設定されているオンネット DN（1234）にダイヤルするとします。ロケーション ベースのコール アドミッション制御によってコールが拒否された場合、AAR は New York の電話の外部電話番号マスク（212555XXXX）を取得して使用し、公衆網上でルーティング可能な完全修飾番号（2125551234）を導出します。

San Francisco から New York へのコールを公衆網でルーティングするには、電話番号のプレフィックスとして「1」が必要です。このプレフィックスは、電話の外部電話番号マスクには含めないことをお勧めします。この電話からオフネットの宛先に発信されるコールでは、このプレフィックスが Calling Party Identification（CallerID）の一部として表示されるためです。代わりに、AAR グループ設定の一部として「1」を追加することをお勧めします。

同じ Cisco Unified CallManager クラスタの内部で複数の国にわたる配置を実現するには、外部電話番号マスクを設定するときに、プレフィックス番号を付けるだけで同じ国または別の国から宛先電話機に到達できるようにする必要があります。つまり、国内であることを示すプレフィックス（多くの国では 0）は、それらが E.164 アドレスの一部でない場合、外部電話番号マスクには含めないでください。

この状況を十分に理解するために、London（英国）、Paris（フランス）、Nice（フランス）にサイトがある Cisco Unified CallManager クラスタの例を考えます。Paris の DID 範囲の E.164 アドレスは、+33145678XXX です。ただし、フランスの公衆網内からコールする場合、これらの内線には、通常は 0145678XXX として到達します。

London のオフィスにいる人物が Paris のオフィスに公衆網経由でダイヤルする場合、ダイヤル ストリングは 90033145678XXX です。一方で、Nice のオフィスにいる人物が Paris のオフィスに公衆網経由でダイヤルする場合、ダイヤル ストリングは 00145678XXX です。したがって、Paris のオフィスにある電話の外部電話番号マスクは、通常のフランス国内番号 0145678XXX ではなく、この場合 145678XXX に設定する必要があります。このマスクに 0 を含めた場合、単に追加番号をプレフィックスとして付加するだけでは、ストリング 90033145678XXX を取得できなくなります。

必要なアクセス コードの付加

宛先番号が元の支店のダイヤル プランによって正常にルーティングされるためには、オフネット アクセス コードのプレフィックス（たとえば 9）が必要になる場合もあります。また、発信地点が別のエリア コード（番号計画エリア（NPA）とも呼ばれます）内に配置されている場合、ダイヤル ストリングの一部として、プレフィックス「1」が必要になります。AAR を設定する場合は、DN を AAR グループ内に配置します。AAR グループのペアごとに、同じ AAR グループ内で発信または終端するコールのプレフィックス番号も含めて、その 2 グループ間のコールで DN に追加するプレフィックス番号を設定できます。

一般的な規則として、複数の DN が次の特性をすべて共有している場合は、それらを同じ AAR グループに配置します。

• 共通のオフネット アクセス コード（たとえば 9）

• エリア間コールにおける共通の公衆網ダイヤリング構造（たとえば、北米では 1-NPA-NXX-XXXX）

• 共通の外部電話番号マスク形式

たとえば、San Francisco と New York の両方のサイトで、上の特性がすべて共通しているとします。San Francisco と New York の DN を 1 つの AAR グループに配置して、この AAR グループ内で発生した AAR コールにプレフィックス 91 を付けるようにこのグループを設定します。San Francisco の電話 A が New York の電話 B（212 555 1234）に到達するには、ダイヤル ストリングにプレフィックス 91 を付けるように AAR グループを設定して、全体で 91 212 555 1234 というストリングが完成されるようにします。

複数の国にわたる配置では、通常は国ごとに少なくとも 1 つの AAR グループが必要です。前の項で示した例について考えると、2 つの AAR グループを定義することができます。UK AAR グループ（London にあるすべての DN に割り当てられるグループ）と France AAR グループ（Paris と Nice にあるすべての DN に割り当てられるグループ）です。UK AAR グループは、France AAR グループに向かうコールにプレフィックス 90033 を付加するように設定します。一方、France AAR グループは、同じ AAR グループ内でのコールに対して 00 のみをプレフィックスとして付加するようにします。

適切なダイヤル プランおよびルートの選択

AAR コールは、発信元の電話と同じロケーションにあるゲートウェイを通じて出力する必要があります。これによって、完成されたダイヤル ストリングが、発信元サイトのダイヤル プランを通じて送信されます。このように設定するには、Cisco Unified CallManager Administration のデバイス設定ページで、適切な AAR コーリング サーチ スペースを選択します。AAR コーリング サーチ スペース内で、オフネット ダイヤル プラン項目（たとえば、ルート パターン）を、同じ場所にあるゲートウェイを指し、公衆網にコールを転送する前にアクセス コードを削除するように設定します。

たとえば、San Francisco サイトの電話を設定する場合は、91-NPA-NXX-XXXX としてダイヤルされた長距離電話を許可し、アクセス コード（9）を削除して San Francisco のゲートウェイに送信する AAR コーリング サーチ スペースを使用します。

（注） オンネット社内コールを強制的に公衆網コールとしてダイヤルする追加のルート パターンを設定した場合は、それらのパターンが AAR 機能のものと一致しないことを確認します。詳細については、「マルチサイト配置用の設計ガイドライン」を参照してください。

（注） コール アドミッション制御による再ルーティングされたコールの拒否を避けるため、AAR 機能は、各エンドポイントとそれに関連する公衆網へのゲートウェイとの間で、IP パスとして LAN を使用する必要があります。したがって、AAR ダイヤル プランでは、公衆網へのアクセスを集中型ゲートウェイに依存することができません。

同じローカル ダイヤリング エリアに複数のサイトがある場合の特別な考慮事項

場合によっては、ローカルエリア ダイヤリングを使用できるように AAR ダイヤル ストリングをローカルに修正する必要があります。たとえば、New York にある 2 つのサイトが、同じエリア コード 212 を共有しているとします（図10-12 を参照）。この場合は、91 212 555 1234 としてダイヤルされた番号を 9 555 1234 に変換する必要があります。

この変換を実行する最良の方法は、サイト固有のトランスレーション パターン 91212.555XXXX を設定することです（ドットの前の番号を削除して、先頭に 9 を付加します）。このトランスレーション パターンは、New York サイトの AAR コーリング サーチ スペースのメンバー パーティションにのみ配置します。San Francisco サイトからは、この同じ宛先に 91 212 555 1234 として到達する必要があります。また、New York サイトのダイヤル プランにもこのトランスレーション パターンを配置して、長距離電話としてダイヤルされたローカルに到達可能な番号を適切にルーティングできるようにする必要があります。New York サイトのダイヤル プランでは、9 555 1234 を有効なストリングとして受け付け、このコールを公衆網に送信する前に、ストリングを 555 1234 に変換するようにします。

図10-12 サイト間 AAR コールにおけるダイヤル番号の変換

（注） AAR 機能は、宛先の電話が到達不能であることが検出されても起動しません。したがって、WAN の障害によって AAR 機能が起動することはありません。

エクステンション モビリティ

エクステンション モビリティ機能を使用すると、ユーザが IP Phone にログインしたとき、内線番号、短縮ダイヤル、メッセージ待機インジケータ（MWI）ステータス、コール特権を含めて、そのユーザのプロファイルが自動的にその電話機に適用されるようになります。このメカニズムは、それぞれのエクステンション モビリティ ユーザに関連付けられる、デバイス プロファイルを作成することで成り立っています。デバイス プロファイルは、実質的には仮想 IP Phone であり、1 つまたはそれ以上の回線を設定したり、コール特権や短縮ダイヤルなどを定義したりできます。

IP Phone がログアウト状態になっている（つまり、エクステンション モビリティ ユーザがログインしていない）とき、この IP Phone の特性は、デバイス設定ページと回線設定ページによって決まります。ユーザが IP Phone にログインすると、デバイス設定は変更されませんが、既存の回線設定は Cisco Unified CallManager データベースに保存され、ユーザのデバイス プロファイルの回線設定によって置き換えられます。

エクステンション モビリティの重要な利点の 1 つは、ユーザがどこにいるかにかかわらず、同じ Cisco Unified CallManager クラスタによって制御されている IP Phone にユーザがログインできれば、そのユーザに対して、そのユーザ固有の内線番号で到達できることです。集中型コール処理を使用しているマルチサイト配置に対してエクステンション モビリティを適用すると、地理的に互いに分離している複数のサイトに対して、この機能を展開することができます。

ただし、エクステンション モビリティ機能を 「Automated Alternate Routing」の項で説明している AAR 機能と組み合せる場合は、一定の制限事項があります。図10-13 に示した例について考えます。エクステンション モビリティと AAR を集中型コール処理の Cisco Unified CallManager クラスタに配置していて、San Jose と New York にそれぞれ 1 つのサイトがあります。

図10-13 エクステンション モビリティと AAR

この例では、通常 San Jose を拠点としているエクステンション モビリティ ユーザが、DN 1000 と DID 番号 (408) 555-1000 を持っているとします。このユーザの外部電話番号マスクは、4085551000 と設定されています。このユーザが New York サイトに移動し、ログインします。さらに、San Jose と New York 間の IP WAN 帯域幅がすべて使用されているとします。

San Jose にいる内線番号 1001 のユーザが 1000 にコールすると、AAR が呼び出され、発信側の AAR コーリング サーチ スペースと着信側の AAR グループに基づいて、914085551000 への新しいコールが、San Jose の電話によって試行されます。このコールは、San Jose のゲートウェイを使用して公衆網にアクセスしますが、DID (408) 555-1000 が同じゲートウェイによって所有されているため、公衆網はコールをこのゲートウェイに戻します。San Jose のゲートウェイは、内線番号 1000 を持つ電話へのコールを確立しようとしますが、この電話は現在 New York にあります。New York にアクセスするための帯域幅を使用できないため、AAR 機能がもう一度呼び出され、次の 2 つのうち、いずれかのシナリオが発生します。

• ゲートウェイの AAR コーリング サーチ スペースに外部公衆網ルート パターンが含まれている場合、ループが開始され、San Jose サイトにあるすべての公衆網トランクが使い果たされる。

• 逆に、ゲートウェイの AAR コーリング サーチ スペースに内部の番号のみが含まれている場合は、コールが失敗し、発信者にはファースト ビジー トーンが聞こえる。この場合は、1 つの公衆網コールが発生して 1 つが受信されるため、コールのセットアップ中、San Jose のゲートウェイでは 2 つの公衆網トランクが使用されます。

ヒント ここで説明したようなルーティング ループを防止するには、ゲートウェイ設定ページでコーリング サーチ スペースを設定するときに、必ず内部の宛先のみを含め、同じゲートウェイを含んでいるルート グループやルート リストを指すルート パターンを一切含めないようにします。

この例では、エクステンション モビリティが Cisco Unified Communications の動的な側面を利用しているため、サイト間のコール ルーティングで IP ネットワークを使用する必要があることを中心に説明しています。公衆網に定義されている E.164 番号は静的なものであり、公衆網ネットワークはエクステンション モビリティ ユーザの移動を認識しません。AAR 機能は、コール ルーティングを公衆網に依存しているため、ホーム サイト以外のサイトに移動したエクステンション モビリティ ユーザに対して、この機能を使用して到達することはできません。

（注） ただし、エクステンション モビリティ ユーザが自分のホーム サイトと同じ AAR グループに属するリモート サイトに移動した場合には、使用可能な IP WAN 帯域幅が十分にないとき、そのユーザは AAR 機能を使用して他のサイトへのコールを発信することができます。

ハント リストと回線グループ

「ハント パイロット」は、通常はコール カバレッジや、Skinny Client Control Protocol（SCCP）エンドポイントを通じたコール分配に使用されます。コールの分配には、ハント コンストラクトを使用できます。このハント コンストラクトは、3 層式のアーキテクチャに基づいています。外部コールのルーティングに使用されるアーキテクチャに似たこのアーキテクチャでは、複数層のコール ルーティングと共に、番号操作も可能です。

Cisco Unified CallManager は、着信番号と一致する設定済みハント パイロットを検索し、それを使用して、対応するハント リストを選択します。ハント リストには、コールに使用可能なパスが優先順位順に並べられています。これらのパスは、「回線グループ」と呼ばれます。図10-14 では、Cisco Unified CallManager Release 4.1 以降のハント コンストラクトの 3 層式アーキテクチャを示しています。

（注） Cisco CallManager Release 3.3 以前では、コール カバレッジ機能はハント グループによって提供されていました。このグループは、Telephony Call Dispatcher（TCD）サービスによって制御され、Cisco Attendant Console によっても使用されます。Cisco Unified CallManager Release 4.0 では、ハント パイロット、ハント リスト、および回線グループが導入されました。ただし、このリリースでは、ハント パイロット構造はルート パターン構造と組み合せられ、ハント リストはルート リストと組み合せられていました。Cisco Unified CallManager Release 4.1 以降では、これらの構造は独立しています。表10-3 は、Cisco Unified CallManager Releases 4.0 と 4.1 のハント リストと回線グループ、および Cisco Unified CallManager Releases 3.3 以前で Attendant Console を使用したハント グループの機能比較を示しています。

比較のために、図10-14 に Cisco Unified CallManager 4.1 以上のハント パイロットのアーキテクチャを示し、図10-15 に Cisco Unified CallManager 4.0 のハント パイロットのアーキテクチャを示します。

図10-14 Cisco Unified CallManager Release 4.1 のハント アーキテクチャの 3 層式アーキテクチャ

図10-15 Cisco Unified CallManager Release 4.0 のハント アーキテクチャ

ハント パイロット

ハント パイロットは、コールをディレクトリ番号にルーティングするために Cisco Unified CallManager で設定された、ルート パターンのように数字とワイルドカードを組み合せたストリング（たとえば、9.[2-9]XXXXXX）です。ハント パイロットは、ハント リストを直接指しています。ハント リストは回線グループを指しており、回線グループは、最終的に SCCP エンドポイントを指しています。

Cisco Unified CallManager Release 4.1 以降では、ハンティングが次のいずれかまたは両方の理由で失敗した場合、コールを最終的な宛先に転送することができます。

• すべてのハンティング オプションを使い果たしても、コールはまだ応答されていない。

• タイムアウト期間が満了した。

このコール転送は、Hunt Pilot 設定ページの Hunt Forward Settings セクションで設定します。この転送の宛先は、次のいずれかから選択できます。

• Cisco Unified CallManager の内部コール ルーティング テーブルに含まれている、特定のパターン。

• 個人用プリファレンス。このプリファレンスは、元々の着信番号の Call Forward No Coverage 設定を指しています。

たとえば、個人用プリファレンス オプションを実装するには、Forward No Answer フィールドに従ってコールをハント パイロットへ転送するようにユーザの電話を設定して、コールに応答できるユーザが他にいないかどうか検索できるようにします。すべてのハンティング オプションが使い果たされたか、タイムアウト期間が満了したためにコール ハンティングが失敗した場合、コールを当初の宛先ユーザが設定している宛先に転送することができます。たとえば、ユーザの DN 設定ページにある Forward No Coverage フィールドにボイスメール番号を設定すると、ハンティングが失敗した場合、コールはそのユーザのボイスメール ボックスに送信されます。

（注） Cisco Unified CallManager Release 4.0 は、コール転送をサポートしていません。

ハント パイロットの処理するコールには、次の考慮事項が適用されます。

• コール ピックアップとグループ コール ピックアップは、ハント パイロットが分配するコールではサポートされません。回線グループのメンバーは、回線グループの他のメンバーに提供されたハント パイロット コールについては、メンバー同士が同じコール ピックアップ グループに属している場合でもピックアップできません。

• ハント パイロット番号に基づいて分配されるコールは、回線グループ内のディレクトリ番号に対して設定される、個別の自動転送処理をサポートしていません。このため、Immediate Divert（iDivert）ソフトキーや、ディレクトリ番号に対して設定されている自動転送は、ハント パイロットが分配するコールに対しては機能しません。回線グループの設定でハント オプションとして使用できる自動転送条件のみが、ハント パイロット コールに適用されます。ただし、iDivert ソフトキーや自動転送設定は、ハント パイロットが分配したコールを除く、すべての着信コールで機能します。

• ハント パイロットは、自身の回線グループのメンバーとハント パイロットが別のパーティションに配置されている場合でも、コールを自身の回線グループのいずれかのメンバーに分配できます。ハント パイロットが分配するコールは、すべてのパーティションおよびコーリング サーチ スペース制限を上書きします。

ハント リスト

ハント リストは、コール カバレッジに使用できるパス（回線グループ）が優先順位順に並べられたリストです。ハント リストには次の特性があります。

• 複数のハント パイロットが同一ハント リストを指すことができます。

• ハント リストは、ハント パイロット番号へのコールが行われたときに提供される代替電話機セットとして機能する回線グループが、優先順位順に並べられたリストです。たとえば、特定のサイトにある一連の電話機の中から、コールを受け取る電話機を見つけるために使用できます。コールが受け取られない場合、ハント リストは第 2 のサイトにある電話機を指定する、第 2 の回線グループを通じたコールの提供を試みます。

• ハント リストは、番号操作は一切実行しません。

• 複数のハント リストに、同じ回線グループを含めることができます。

回線グループ

回線グループのメンバーは、Cisco Unified CallManager が制御しているユーザ内線番号です。このため、コールを回線グループのメンバー間に分配するときは、Cisco Unified CallManager がコールを制御します。コールが応答されなかった場合や、内線番号が使用中または未登録の場合は、ハント オプションをコールに適用できます。

回線グループは、コールが分配される順序を制御し、次の特性を持っています。

• 回線グループは、特定の内線番号（通常は、IP Phone 内線番号またはボイスメール ポート）を指しています。

• 1 つの内線番号が複数の回線グループに含まれていることがあります。

• コンピュータ/テレフォニー インテグレーション（CTI）ポートと CTI ルート ポイントは、回線グループに追加できません。したがって、CTI アプリケーション（Cisco Customer Response Solutions（CRS）や IP 音声自動応答装置（IP IVR）など）を通じて制御されるエンドポイントには、コールを分配できません。

• Cisco Unified CallManager は、割り当てられている分配アルゴリズムに従ってコールを各デバイスに分配します。Cisco Unified CallManager は、次のアルゴリズムをサポートしています。

–トップダウン

–循環

–最長アイドル時間

–ブロードキャスト

• No-Answer、Busy、Not-Available のいずれかのイベントが発生すると、分配されたコールを回線グループがハント オプションに基づいて内線番号に転送します。Cisco Unified CallManager は、次のハント オプションをサポートしています。

–次のメンバーにアクセスし、その後はハント リスト内の次のグループにアクセスする。

–次のメンバーにアクセスするが、次のグループにはアクセスしない。

–残りのメンバーをスキップして、次のグループに直接アクセスする。

–ハンティングを停止する。

ハント アルゴリズムとハント オプションの詳細については、次の Web サイトで入手可能な『 Cisco Unified CallManager Administration Guide 』を参照してください。

http://www.cisco.com

回線グループ デバイス

回線グループ デバイスは、回線グループがアクセスするエンドポイントであり、次のいずれかのタイプに該当します。

• Skinny Client Control Protocol（SCCP）エンドポイント（Cisco Unified IP Phone、VG248、ATA 188 など）

• SIP エンドポイント（Cisco Unified CallManager 5.0 が必要）

• ボイスメール ポート（Cisco Unity）

• H.323 クライアント

• MGCP ゲートウェイに接続されている FXS

時間帯ルーティング

Cisco Unified CallManager Release 4.1 では、Time-of-Day（ToD）ルーティング機能が導入されました。この機能を使用するには、次の要素を設定します。

• 期間

• タイム スケジュール

期間を利用すると、営業開始時刻と終了時刻を設定できます。この開始時刻と終了時刻は、コールをルーティングできる期間を示しています。これらの時刻に加えて、毎週または毎年発生するイベントを設定することもできます。さらに、Start Time オプションと End Time オプションにある No business hours を選択して、休業時間を設定することもできます。このオプションを選択した場合は、すべての着信コールがブロックされます。

タイム スケジュールは、パーティションに割り当てられている特定の期間をグループにまとめたものです。このタイム スケジュールによって、指定した期間中にパーティションがアクティブまたは非アクティブのどちらになっているかが判断されます。一致したパターンやダイヤリング パターンには、そのダイヤリング パターンの配置されているパーティションがアクティブになっている場合のみ到達できます。

図10-16 では、同じコール パターン（8000）を持つ 2 つのハント パイロットが、2 つのパーティション（RTP_Partition、SJC_Partition）内に設定されています。これらのパーティションには、一連の定義済み期間を保持したタイム スケジュールがそれぞれ割り当てられています。たとえば、RTP の電話には、ハント パイロット 1 を使用することで、月曜日から金曜日の午前 8 時～ 午後 12 時（東部標準時。GMT - 5.00）まで、および日曜日の午前 8 時から午後 5 時まで到達できます。同様に、SJC の電話には、ハント パイロット 2 を使用することで、月曜日から金曜日の午前 8 時～午後 5 時（太平洋標準時。GMT - 8.00）まで、および土曜日の午前 8 時～午後 5 時まで到達できます。この例では、どちらのハント パイロットも 7 月 4 日は非アクティブです。

図10-16 時間帯ルーティング

図10-16 の例では、水曜日の午後 3 時にハント パイロット（8000）に着信したコールは、SJC の電話に転送されます。一方、このハント パイロットに 7 月 4 日にコールした人は、別のパターンが 8000 に一致しない限り、ファースト ビジー トーンを受信します。

H.323 ダイヤル ピアを使用する Cisco IOS でのコール ルーティング

H.323 プロトコルを使用する Cisco IOS ルータ上でのコール ルーティング ロジックは、ダイヤル ピア コンストラクトに依存しています。ダイヤル ピアは、スタティック ルートに似たものです。コールの発信地点と終端地点、およびコールがネットワークで通過するパスを定義しています。ダイヤル ピアは、コールの発信元と宛先のエンドポイントを指定するため、およびコール接続の各コール レッグに適用される特性を定義するために使用します。ダイヤル ピアに含まれている属性によって、ダイヤルされるどの番号をルータが収集し、テレフォニー デバイスに転送するかが決まります。

ダイヤル ピアおよびその設定の詳細については、次の Web サイトで入手可能な『 Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2 』の「 Configuring Dial Plans, Dial Peers, and Digit Manipulation 」を参照してください。

http://www.cisco.com

ダイヤル ピアを使用したコール ルーティングを理解するための鍵の 1 つは、着信コール レッグと発信コール レッグ、つまり着信ダイヤル ピアと発信ダイヤル ピアという概念です。Cisco IOS ルータを経由する各コールは、2 つのコール レッグを持っていると見なされます。1 つはルータに入るもので、1 つはルータから出るものです。ルータに入るコール レッグが「着信コール レッグ」であり、ルータから出るコール レッグが「発信コール レッグ」です。

コール レッグには、主に次の 2 つのタイプがあります。

• ルータを公衆網、アナログ電話機、または PBX に接続する、従来の TDM テレフォニー コール レッグ

• ルータを他のゲートウェイ、ゲートキーパー、または Cisco Unified CallManager に接続する、IP コール レッグ

Cisco IOS は、ルータを通過するすべてのコールについて、1 つのダイヤル ピアを各コール レッグに関連付けます。ダイヤル ピアにも、関連付け先となるコール レッグのタイプに応じて、次に示す主に 2 つのタイプがあります。

• 従来の TDM テレフォニー コール レッグに関連付けられる、POTS ダイヤル ピア

• IP コール レッグに関連付けられる、VoIP ダイヤル ピア

図10-17 では、Cisco IOS ルータを通過する、次の各種コールの例を示しています。

• コール 1 は、IP ネットワークにある別の H.323 ゲートウェイから、ルータに接続されている従来の（たとえば、PRI インターフェイス経由の）PBX までです。このコールに対しては、着信 VoIP ダイヤル ピアと発信 POTS ダイヤル ピアが選択されます。

• コール 2 は、ルータの FXS ポートに接続されているアナログ電話機から、IP ネットワークにある Cisco Unified CallManager クラスタまでです。このコールに対しては、着信 POTS ダイヤル ピアと発信 VoIP ダイヤル ピアがルータによって選択されます。

• コール 3 は、Cisco Unified CallManager Express または SRST の制御する IP Phone から、ルータ上の公衆網インターフェイス（たとえば、PRI インターフェイス）までです。このコールに対しては、自動生成の POTS ダイヤル ピア（ルータ上に設定されている ephone に対応します）と発信 POTS ダイヤル ピアが選択されます。

図10-17 着信ダイヤル ピアと発信ダイヤル ピア

着信コール レッグを着信ダイヤル ピアと対応付けるために、ルータは、セットアップ メッセージ内の情報要素（着信番号/DNIS と発信番号/ANI）が 4 つの設定可能ダイヤル ピア属性と一致するかどうか調べることによって、ダイヤル ピアを選択します。ルータは、これらの項目が一致するかどうかを次の順序で調べます。

1. 着信番号と incoming called-number

2. 発信番号と answer-address

3. 着信番号と destination-pattern

4. 着信音声ポートと設定済み音声ポート

ルータで必要となるのは、これらの条件のいずれか 1 つのみ一致することです。すべての属性をダイヤル ピア内に設定する必要はなく、すべての属性がコール セットアップ情報に一致している必要はありません。ルータがダイヤル ピアを選択するために必要な条件は 1 つのみです。ルータは、1 つのダイヤル ピアが一致するとすぐに検索を停止し、コールは設定済みのダイヤル ピア属性に従ってルーティングされます。一致するダイヤル ピアが他にある場合でも、最初に一致したピアのみが使用されます。

ルータが発信ダイヤル ピアを選択する方法は、着信 POTS ダイヤル ピアに direct-inward-dial （DID）が設定されているかどうかによって異なります。

• 着信 POTS ダイヤル ピアに DID が設定されていない場合、ルータは 2 段階ダイヤリングを実行し、着信ダイヤル ストリングを 1 桁ずつ収集します。1 つのダイヤル ピアが宛先パターンに一致すると、ルータは一致したダイヤル ピアの設定済み属性を使用して、コールをただちに発信します。

• 着信 POTS ダイヤル ピアに DID が設定されている場合、ルータは着信番号全体を使用して、発信ダイヤル ピアに含まれている宛先パターンに一致するかどうかを調べます。DID を使用する場合は、コールのルーティングに必要な番号がセットアップ メッセージにすべて含まれているため、番号をそれ以上収集する必要がありません。複数のダイヤル ピアがダイヤル ストリングに一致した場合、一致するすべてのダイヤル ピアが「ハント グループ」の形成に使用されます。ルータは、発信コール レッグを確立できるまで、ハント グループに含まれているすべてのダイヤル ピアを使用して確立を試行します。

デフォルトでは、ハント グループ内のダイヤル ピアは、次の基準を使用して、この順序に従って選択されます。

1. 電話番号の最長一致

この方法では、ダイヤルされた番号と一致している部分が最も長い宛先パターンが選択されます。たとえば、あるダイヤル ピアがダイヤル ストリング 345.... を使用して設定され、2 番目のダイヤル ピアが 3456789 を使用して設定されている場合、ルータはまず 3456789 を選択します。2 つのダイヤル ピアのうち、正確に一致している部分が最も長いためです。

2. 明示的プリファレンス

この方法では、 preference ダイヤル ピア コマンドで設定した優先順位を使用します。プリファレンスの数値が小さくなるほど、優先順位が高くなります。最高の優先順位は、プリファレンス順位 0 のダイヤル ピアに与えられます。同じ宛先パターンを持つ複数のダイヤル ピアに対して同じ優先順位が定義されている場合、ダイヤル ピアはランダムに選択されます。

3. ランダム選択

この方法では、すべての宛先パターンが同等の重みになります。

このデフォルト選択順序を変更することも、 dial-peer hunt グローバル設定コマンドを使用して、別のダイヤル ピア ハンティング方法を選択することもできます。このほかの選択基準は、「最長待機時間」です。最後に選択された時点から、最も長く待機している宛先パターンを選択します（Cisco Unified CallManager 回線グループの「最長アイドル時間」に相当します）。

Cisco IOS ルータ上で H.323 ダイヤル ピアを設定するときは、次のベスト プラクティスに従ってください。

• 着信公衆網コールが DNIS 情報に基づいて宛先に直接ルーティングされるようにするには、 direct-inward-dial 属性を使用して、次のようにデフォルト POTS ダイヤル ピアを作成します。

• ルータを Cisco Unified CallManager クラスタに接続されている H.323 ゲートウェイとして使用する場合は、同じ宛先パターンを持ち、2 つの異なる Cisco Unified CallManager サーバを指す VoIP ダイヤル ピアを少なくとも 2 つ設定して、冗長性を実装します。プライマリとセカンダリの Cisco Unified CallManager サーバ間での優先順位を選択するには、 preference 属性を使用します。次に preference 属性の使用例を示します。

ゲートキーパーを使用する Cisco IOS でのコール ルーティング

H.323 ゲートキーパーは、H.323 ネットワークにあるエンドポイント（Cisco Unified CallManager Express および Cisco Unified CallManager のクラスタ、H.323 端末、ゲートウェイ、マルチポイント コントロール ユニット（MCU）など）を管理するためのオプション ノードであり、それらのエンドポイントにコール ルーティング機能とコール アドミッション制御機能を提供します。エンドポイントは、H.323 Registration Admission Status（RAS）プロトコルを使用してゲートキーパーと通信します。

エンドポイントは、起動するとゲートキーパーへの登録を試行します。他のエンドポイントとの通信が必要な場合は、E.164 アドレスや電子メール アドレスなど、自身のシンボリック エイリアスを使用して、コールを開始するための許可を要求します。ゲートキーパーは、そのコールを許可してもよいと判断した場合、宛先の IP アドレスを発信元エンドポイントに返します。この IP アドレスは、宛先エンドポイントの実際の IP アドレスではなく、中継アドレスである場合もあります。たとえば、IP-to-IP ゲートウェイや、コール シグナリングをルーティングするゲートキーパーのアドレスです。

H.323 プロトコル、および H.323 エンドポイントとゲートキーパーとのメッセージ交換の詳細については、次の Web サイトで入手可能な『 Cisco IOS H.323 Configuration Guide 』を参照してください。

http://www.cisco.com

Cisco 2600、3600、3700、2800、3800、および 7200 シリーズのルータはすべて、ゲートキーパー機能をサポートします。冗長性、ロード バランシング、および階層コール ルーティング用に、さまざまな方法で Cisco IOS ゲートキーパーを設定できます。ここでは、ゲートキーパー機能のコール ルーティング機能を中心に説明します。冗長性とスケーラビリティに関する考慮事項については、「ゲートキーパーの冗長性」を参照してください。コール アドミッション制御に関する考慮事項については、「Cisco IOS ゲートキーパー ゾーン」を参照してください。

Cisco IOS ゲートキーパーのコール ルーティングは、次のタイプの情報に基づいています。

• 静的に設定されている情報（ゾーン プレフィックスや、デフォルト テクノロジー プレフィックスなど）

• 動的な情報（登録フェーズで H.323 デバイスが提供した E.164 アドレスやテクノロジー プレフィックスなど）

• コールごとの情報（着信番号やテクノロジー プレフィックスなど）

ゾーンは、エンドポイント、ゲートウェイ、MCU などの、ゲートキーパーに登録される H.323 デバイスの集合です。アクティブになることができるゲートキーパーは、ゾーンごとに 1 つのみです。1 つのゲートキーパーには、ローカル ゾーンを 100 個まで定義できます。

H.323 エンドポイントがゲートキーパーに登録すると、エンドポイントはゾーンに割り当てられます。また、処理できるコールの種類（音声、ビデオ、ファックスなど）を指定するテクノロジー プレフィックスとともに、処理を担当している 1 つまたはそれ以上の E.164 アドレスを登録することもできます。

ゾーンごとに、ゲートキーパー上で 1 つまたはそれ以上の「ゾーン プレフィックス」を設定できます。ゾーン プレフィックスは、番号とワイルドカードを含んだストリングであり、ゲートキーパーがコール ルーティングの判断に使用します。ゾーン プレフィックス ストリングでは、次の文字を使用できます。

• 0 ～ 9 までのすべての数字。それぞれが特定の 1 桁に対応

• ドット（.）ワイルドカード。いずれかの 1 桁の 0 ～ 9 までの数字に対応

• * ワイルドカード。1 またはそれ以上の桁の 0 ～ 9 までの数字に対応

ゲートキーパーのコール ルーティング動作を理解するには、メッセージ解析ロジックについて考えると役立ちます。図10-18 では、アドミッション要求（ARQ）の解析ロジックを示しています。エンドポイントは、コールを初期化するために、ARQ（Admission Request ; アドミッション要求）をゲートキーパーに送信します。ARQ には、宛先つまり着信側の H.323 ID または E.164 アドレスのどちらか、および送信元つまり発信側の E.164 アドレスまたは H.323 ID が含まれています。

ARQ に E.164 アドレスが入っている（Cisco Unified CallManager では、ARQ には常に E.164 アドレスが入っています）場合、ARQ にはテクノロジー プレフィックスが含まれている場合と、含まれていない場合があります。ARQ にテクノロジー プレフィックスが含まれている場合、ゲートキーパーはテクノロジー プレフィックスを着信番号から削除します。ARQ にテクノロジー プレフィックスが含まれていない場合、ゲートキーパーは、デフォルトのテクノロジー プレフィックスが設定されていれば、それを使用します（「集中型ゲートキーパー設定」の項の gw-type-prefix コマンドを参照）。このように取得したテクノロジー プレフィックスは、メモリに格納され、ゲートキーパーはコール ルーティング アルゴリズムに基づく処理を続行します。

次に、ゲートキーパーは、着信番号が設定済みのいずれかのゾーン プレフィックスに一致しないかどうかを調べます。一致する可能性のあるエントリが複数ある場合は、一致する部分の最も長いものが使用されます。一致するゾーン プレフィックスがない場合、未知のプレフィックスを持つコールを受け付けるようにゲートキーパーが設定されているときは、ゲートキーパーは宛先ゾーンが発信元ゾーンと同じであると想定します。

この時点で、ゲートキーパーは選択された宛先ゾーン内を検索して、着信番号に一致する登録済み E.164 アドレスがあるかどうかを調べます。一致が見つかると、コールに関して要求した帯域幅が使用可能になっていて、着信側エンドポイントがゲートキーパーに登録されている場合、ゲートキーパーはアドミッション確認（ACF）を送信します。ACF には、宛先エンドポイントの IP アドレスが入っています。帯域幅が使用不能であるか、着信側エンドポイントが登録されない場合、ゲートキーパーは、発信側エンドポイントに ARJ（Admission Reject ; アドミッション拒否）を戻します。

一致する E.164 アドレスが宛先ゾーン内に登録されていない場合、ゲートキーパーは、以前に格納したテクノロジー プレフィックスを使用して、そのゾーンに登録されているゲートウェイをコールの宛先として選択します。ゲートキーパーが ACF または ARJ のどちらを発信元エンドポイントに送信するかは、帯域幅の可用性とエンドポイントの登録に関する、上と同じ考慮事項に基づいて決まります。

送信元エンドポイントは、ゲートキーパーから ACF を受信した後、ACF で戻された IP アドレスを使用して、直接セットアップ メッセージを宛先エンドポイントに送信できます。

図10-18 ARQ のゲートキーパー アドレス解決

図10-19 では、ロケーション要求（LRQ）の解析ロジックを示しています。LRQ メッセージは、ゲートキーパー間で交換され、ゾーン（リモート ゾーン）間のコールに使用されます。たとえば、ゲートキーパー A が ARQ をローカル ゾーンのゲートウェイから受信し、その ARQ は、リモート ゾーンのデバイスに対するコール アドミッションを要求しているとします。ゲートキーパー A は、ゲートキーパー B に LRQ メッセージを送信します。ゲートキーパー B は、自身がゾーン間コール要求を許可するように設定されているかどうか、および要求されたリソースが登録されているかどうかに応じて、この LRQ メッセージにロケーション確認（LCF）メッセージまたはロケーション拒否（LRJ）メッセージで応答します。

図10-19 LRQ のゲートキーパー アドレス解決

従来の Cisco IOS ゲートキーパー機能は、「中継ゾーン」ゲートキーパーという概念を通じて、IP-to-IP ゲートウェイに対応するように拡張されました。配置の例については、「RSVP 機能のある Cisco IOS Gatekeeper および IP-to-IP ゲートウェイ」を参照してください。

中継ゾーン ゲートキーパーがレガシー ゲートキーパーと異なっている点は、コール ルーティングでの LRQ メッセージと ARQ メッセージの使用方法です。中継ゾーン ゲートキーパーを使用しても、通常のクラスタおよび機能はそのまま使用できます。レガシー ゲートキーパーは、着信する LRQ を着信番号に基づいて検査します。具体的には、LRQ の destinationInfo 部分にある dialedDigits フィールドを検査します。中継ゾーン ゲートキーパーは、着信番号を検査する前に LRQ の発信地点を検査します。LRQ が、中継ゾーン ゲートキーパーのリモート ゾーン設定にリストされているゲートキーパーから送信されている場合、ゲートキーパーは、ゾーンのリモート設定に invia キーワードまたは outvia キーワードが含まれているかどうかを確認します。設定にこれらのいずれかのキーワードが含まれている場合、ゲートキーパーは中継処理をします。含まれていない場合は、従来の処理をします。

ARQ メッセージの場合、ゲートキーパーは宛先ゾーンに outvia キーワードが設定されているかどうかを調べます。 outvia キーワードが設定されていて、 outvia キーワードを使用して命名されているゾーンがゲートキーパーに対してローカルである場合は、そのゾーンの IP-IP ゲートウェイがポイントされている ACF が返され、コールは IP-IP ゲートウェイに転送されます。 outvia キーワードを使用して命名されているゾーンがリモートである場合、ゲートキーパーは、ロケーション要求（LRQ）をリモート ゾーンのゲートキーパーではなく outvia ゲートキーパーに送信します。 invia キーワードは、ARQ の処理では使用されません。

集中型ゲートキーパー設定

単一のゲートキーパーは、クラスタ間のコール ルーティング、および最大 100 の Cisco Unified CallManager クラスタに対するコール アドミッション制御をサポートできます。図10-20 では、2 つの Cisco Unified CallManager クラスタと単一の集中型ゲートキーパーを備えた分散型コール処理環境を示しています。

図10-20 2 つのクラスタをサポートする集中型ゲートキーパー

例10-1 では、図10-20 のゲートキーパー設定を示しています。

例10-1 集中型ゲートキーパーの設定

ここでは、図10-20 について説明します。

• Cisco Unified CallManager トランク登録をサポートするために、各 Cisco Unified CallManager クラスタにはローカル ゾーンが設定されます。

• ゾーン間とクラスタ間のコール ルーティングを可能にするために、ゾーンごとにゾーン プレフィックスが設定されます。

• サイトごとに帯域幅ステートメントが設定されます。シスコでは、 bandwidth interzone コマンドを使用することをお勧めします。 bandwidth total コマンドを使用すると、設定内容によっては問題が発生することがあるためです。帯域幅はキロビット/秒（kbps）単位で測定されます。

• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。

テクノロジー プレフィックスは、発信されているコールのタイプを示しています。テクノロジー プレフィックスとして使用される個々の値は任意のものであり、ネットワーク管理者が定義します。配置全体で常に同じ値を使用する必要があります。

テクノロジー プレフィックスは、E.164 アドレス（電話番号）のプレフィックスとして送信され、コールが音声であるか、ビデオであるか、その他のタイプであるかを示します。# シンボルは、一般に、プレフィックスと E.164 番号を区別するために使用します。プレフィックスが含まれていない場合、コールのルーティングにはデフォルトのテクノロジー プレフィックスが使用されます。配置全体で 1 つのデフォルト テクノロジー プレフィックスだけが使用される場合があります。

Cisco IOS ゲートウェイは、プレフィックスが設定されていれば、自動的に発信コールにテクノロジー プレフィックスを追加します。ゲートウェイは、自動的に着信 H.323 コールからプレフィックスを除去します。Cisco Unified CallManager は、ゲートキーパー制御 H.323 トランクの設定ページで指定されているテクノロジー プレフィックスを使用して、ゲートキーパーに登録することができます。ただし、このテクノロジー プレフィックスは、ゲートキーパーに向かう発信コールに自動的に追加されることはありません。また、Cisco Unified CallManager に向かう着信コールから自動的に除去されることもありません。トランスレーション パターンとゲートウェイ コンフィギュレーションを使用して着信番号を操作すると、テクノロジー プレフィックスを必要に応じて追加または除去できます。

• arq reject-unknown-prefix コマンドは、冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避します。

分散型ゲートキーパー設定

帯域幅を節約するため、または WAN 障害時に H.323 ゲートウェイにローカル コール ルーティングをサポートするために、ゲートキーパーを分散させることができます。図10-21 は、2 つのクラスタと 2 つのゲートキーパーを備えた分散型コール処理環境を示しています。

図10-21 2 つのクラスタをサポートする分散型ゲートキーパー

例10-2 は、図10-21 のサイト 1 に対するゲートキーパー設定を示しています。

例10-2 サイト 1 のゲートキーパー設定

ここでは、例10-2 について説明します。

• ローカル Cisco Unified CallManager クラスタ トランクの登録用に、ローカル ゾーンが設定されます。

• サイト 2 のゲートキーパーへのコール ルーティング用に、リモート ゾーンが設定されます。

• ゾーン間コール ルーティング用に、両方のゾーンにゾーン プレフィックスが設定されます。

• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、 bandwidth remote コマンドを使用します。

• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。

• arq reject-unknown-prefix コマンドは、冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避します。

例10-3 は、図10-21 のサイト 2 に対するゲートキーパー設定を示しています。

例10-3 サイト 2 のゲートキーパー設定

ここでは、例10-3 について説明します。

• ローカル Cisco Unified CallManager クラスタ トランクの登録用に、ローカル ゾーンが設定されます。

• サイト 1 のゲートキーパーへのコール ルーティング用に、リモート ゾーンが設定されます。

• ゾーン間コール ルーティング用に、両方のゾーンにゾーン プレフィックスが設定されます。

• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、 bandwidth remote コマンドを使用します。

• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。

• arq reject-unknown-prefix コマンドは、冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避します。

ディレクトリ ゲートキーパーを使用した分散型ゲートキーパー設定

ゲートキーパー ルーティング テーブルを更新するために使用できるゲートキーパー プロトコルがないので、ディレクトリ ゲートキーパーを使用すると、分散型ゲートキーパー設定のスケーラビリティとマネージャビリティの向上に役立ちます。ディレクトリ ゲートキーパーを実装すると、各サイトのゲートキーパー設定が簡単になり、ゾーン間通信の大部分の設定をディレクトリ ゲートキーパーでできるようになります。

ディレクトリ ゲートキーパーがない場合、ゲートキーパーに新しいゾーンを追加するたびに、ネットワーク上のすべてのゲートキーパーに項目を追加する必要があります。しかし、ディレクトリ ゲートキーパーを使用すると、ローカル ゲートキーパーとディレクトリ ゲートキーパーのみで新しいゾーンを追加できます。ローカル ゲートキーパーは、コール要求をローカル側で解決できない場合、ゾーン プレフィックスが一致するディレクトリ ゲートキーパーにその要求を転送します。

図10-22 では、ローカル コール ルーティング用の分散型ゲートキーパー、およびゲートキーパー間のコール ルーティングをサポートするディレクトリ ゲートキーパーを備えた、Cisco Unified CallManager 分散型コール処理環境を示しています。

図10-22 ディレクトリ ゲートキーパーを備えた分散ゲートキーパー

例10-4 では、図10-22 のサイト 1 に対するゲートキーパー設定を示しています。この例では、サイト 1 とサイト 2 のゲートキーパー設定がほぼ同じなので、ここでは、サイト 1 だけについて説明します。

例10-4 ディレクトリ ゲートキーパーを使用したサイト 1 のゲートキーパー設定

ここでは、例10-4 について説明します。

• ローカル Cisco Unified CallManager クラスタ トランクの登録用に、ローカル ゾーンが設定されます。

• ディレクトリ ゲートキーパー用にリモート ゾーンが設定されます。

• ゾーン間コール ルーティング用に、両方のゾーンにゾーン プレフィックスが設定されます。

• ディレクトリ ゲートキーパーのゾーン プレフィックスは、10 個のドットを使用して設定されます。このパターンは、未解決の任意の 10 桁のダイヤル ストリングと一致します。1 つのゾーンに複数のゾーン プレフィックスを設定して、異なる長さのダイヤル ストリングを一致させることができます。ディレクトリ ゲートキーパーのゾーン プレフィックスにもワイルドカード（*）を使用できますが、この方法はコール ルーティングの問題が発生する場合があります。

• ローカル ゾーンとその他の任意のリモート ゾーンとの間の帯域幅を制限するために、 bandwidth remote コマンドを使用します。

• gw-type-prefix 1# default-technology コマンドを使用すると、ローカルで解決されないすべてのコールをローカル ゾーン内でテクノロジー プレフィックス 1# に登録されたデバイスに転送できます。この例では、すべての Cisco Unified CallManager トランクは、1# プレフィックスに登録されるように設定されています。

• arq reject-unknown-prefix コマンドは、冗長 Cisco Unified CallManager トランク上にできるコール ルーティング ループを回避します。

例10-5 では、図10-22 の例のディレクトリ ゲートキーパー設定を示しています。

例10-5 ディレクトリ ゲートキーパー設定

ここでは、例10-5 について説明します。

• ディレクトリ ゲートキーパー用にローカル ゾーンが設定されます。

• リモート ゲートキーパーごとに、リモート ゾーンが設定されます。

• ゾーン間コール ルーティング用に、両方のリモート ゾーンにゾーン プレフィックスが設定されます。設定を簡単にするために、ゾーン プレフィックスでワイルドカード（*）が使用されます。コールは DGK ゾーンにルーティングされないので、DGK ゾーンにはプレフィックスが必要ありません。

• lrq forward-queries コマンドは、ディレクトリ ゲートキーパーが、別のゲートキーパーから受信した LRQ を転送できるようにします。

H.323 ダイヤル ピアを使用する Cisco IOS のコール特権

H.323 を使用する Cisco IOS ベースのシステム（H.323 ゲートウェイ、SRST、および Cisco Unified CallManager Express を含む）にコール特権を実装するには、クラス制限（COR）機能を使用します。この機能は、ネットワークの設計に柔軟性をもたらし、管理者は、すべてのユーザに関して任意のコールをブロックできるようになります（たとえば、米国では 900 番号へのコール）。また、個々の発信者のコール試行に対して、それぞれ別のコール特権を適用できます（一部のユーザには国際通話を許可し、他のユーザには許可しない、など）。

COR 機能の中心となる基本的メカニズムは、着信と発信の「COR リスト」を定義することで成立しています。このリストは既存のダイヤル ピアに関連付けるもので、着信および発信という概念は、Cisco IOS ルータに対してのものです（ダイヤル ピアの場合と同様）。各 COR リストは、メンバーの番号を含めることで定義します。この番号は、Cisco IOS 内に定義済みの単純なタグです。

コールがルータを通過するときには、Cisco IOS ダイヤル ピア ルーティング ロジックに基づいて、着信ダイヤル ピアと発信ダイヤル ピアが選択されます。選択されたダイヤル ピアに COR リストが関連付けられている場合は、コールをルーティングする前に、さらに次のチェックが実行されます。

• 発信ダイヤル ピアに関連付けられている発信 COR リストのメンバーが、着信ダイヤル ピアに関連付けられている着信 COR リストのメンバーのサブセットである場合、コールは許可されます。

• 発信ダイヤル ピアに関連付けられている発信 COR リストのメンバーが、着信ダイヤル ピアに関連付けられている着信 COR リストのメンバーのサブセットではない場合、コールは拒否されます。

COR リスト ステートメントが一切適用されていないダイヤル ピアが存在する場合は、次のプロパティが適用されます。

• ダイヤル ピア上に着信 COR リストが設定されていない場合は、デフォルトの着信 COR リストが使用されます。デフォルト着信 COR リストは最高の優先順位を持っているため、発信 COR リストの内容にかかわらず、このダイヤル ピアは他のすべてのダイヤル ピアにアクセスできます。

• ダイヤル ピア上に発信 COR リストが設定されていない場合は、デフォルトの発信 COR リストが使用されます。デフォルト発信 COR リストは優先順位が最も低いため、着信 COR リストの内容にかかわらず、他のすべてのダイヤル ピアがこのダイヤル ピアにアクセスできます。

この動作の内容を最もよく表しているのが、図10-23 に示す例です。この例では、1 つの VoIP ダイヤル ピアと 2 つの POTS ダイヤル ピアが定義されています。

図10-23 COR の動作の例

この VoIP ダイヤル ピアは、メンバー A、B、C を持つ着信 COR リスト c1 に関連付けられています。着信 COR リストのメンバーは、「鍵」だと考えることができます。

最初の POTS ダイヤル ピアは、宛先パターン 1.. を持っており、メンバー A と B を持つ発信 COR リスト c2 に関連付けられています。2 番目の POTS ダイヤル ピアは、宛先パターン 2.. を持っており、メンバー A、B、D を持つ発信 COR リスト c3 に関連付けられています。発信 COR リストのメンバーは、「錠」だと考えることができます。

コールが成功するには、発信ダイヤル ピアの発信 COR リストにあるすべての「錠」を開けるための「鍵」を、着信ダイヤル ピアの着信 COR リストがすべて持っている必要があります。

図10-23 に示した例では、宛先が 100 になっている最初の VoIP コールがルータに受信されます。Cisco IOS コール ルーティング ロジックによって、着信コール レッグが VoIP ダイヤル ピアに、発信コール レッグが最初の POTS ダイヤル ピアに対応付けられます。次に、COR ロジックが適用されます。c1 着信 COR リストは、c2 発信 COR リストの錠（A と B）に必要な鍵をすべて持っているため、コールは成功します。

次に、宛先が 200 になっている 2 番目の VoIP コールがルータで受信されます。Cisco IOS コール ルーティング ロジックによって、着信コール レッグが VoIP ダイヤル ピアに、発信コール レッグが 2 番目の POTS ダイヤル ピアに対応付けられます。次に、COR ロジックが適用されます。c1 着信 COR リストは、c3 発信 COR リスト（D）に必要な「鍵」を 1 つ持っていないため、コールは拒否されます。

Cisco IOS で COR 機能を設定するには、次の手順に従います。

ステップ 1 コマンド dial-peer cor custom を使用して、COR リスト メンバーとして使用される「タグ」を定義します。

ステップ 2 コマンド dial-peer cor list corlist-name を使用して、COR リストを定義します。

ステップ 3 COR リストを既存の VoIP ダイヤル ピアまたは POTS ダイヤル ピアに関連付けます。このためには、ダイヤル ピアの設定で、コマンド corlist { incoming | outgoing } corlist-name を使用します。

Cisco IOS Release 12.2(8)T 以降では、COR 機能を SRST 制御の IP Phone に適用できます。IP Phone は、SRST ルータに対して動的に登録を実行します。このため、SRST では、IP Phone が Cisco Unified CallManager クラスタへの接続を失うときまで、個々の IP Phone について事前には一切把握していません。したがって、COR 機能の SRST 用の設定は、電話の DN に基づいています。SRST ルータに登録するとき、IP Phone は自身の DN をルータに通知して、SRST ルータが IP Phone を適切な COR リストに割り当てられるようにします。

SRST によって制御される IP Phone のための COR を設定するには、コマンド cor { incoming | outgoing } corlist-name { corlist-number starting-number - ending-number | default } を call-manager-fallback 設定モードで使用します。

このコマンドには、次の制限事項があります。

• Cisco IOS Release 12.2(8)T 以降で使用可能な SRST バージョン 2.0 では、 call-manager-fallback で許容される cor { incoming | outgoing } ステートメントの数は、最大で 5（デフォルト ステートメント含まず）です。

• Cisco IOS Release 12.3(4)T 以降で使用可能な SRST バージョン 3.0 では、 call-manager-fallback で許容される cor { incoming | outgoing } ステートメントの数は、最大で 20（デフォルト ステートメント含まず）です。

COR 機能は、Cisco IOS Release 12.2(8)T 以降を使用する Cisco Unified CallManager Express にも配置できます。個々の IP Phone は、Cisco Unified CallManager Express で具体的に設定されます。したがって、COR リストを IP Phone 自体に直接適用することができます。このためには、コマンド cor { incoming | outgoing } corlist-name を各 IP Phone の ephone-dn dn-tag 設定モードで使用します。

これらの概念を実際に適用する方法の例については、「H.323 を使用している Cisco IOS でのサービス クラスの構築」の項を参照してください。

Cisco SRST と Cisco Unified CallManager Express の設定の詳細については、次の Web サイトで入手可能な『 Cisco SRST 3.0 System Administrator Guide 』および『 Cisco Unified CallManager Express 3.1 System Administrator Guide 』を参照してください。

http://www.cisco.com

H.323 ダイヤル ピアを使用する Cisco IOS での番号操作

H.323 を実行している Cisco IOS ルータでは、番号操作は音声トランスレーション プロファイルを通じて実行されます。このプロファイルは、音声コールの発信番号（ANI）または着信番号（DNIS）の番号を操作するために、またはコールの番号タイプを変更するために使用されるものです。

音声トランスレーション プロファイルは、Cisco IOS Release 12.2(11)T 以降で使用できます。このプロファイルは、コールが着信ダイヤル ピアに対応付けられる前、またはコールが発信ダイヤル ピアによって転送される前に、電話番号を別の番号に変換するために使用します。たとえば、社内で 5 桁の内線番号をダイヤルすると、別のサイトにいる従業員に到達できるとします。コールが他のサイトに公衆網を通じてルーティングされ、到達する場合は、発信側のゲートウェイで音声トランスレーション プロファイルを使用する必要があります。これによって、5 桁の内線番号が公衆網で認識される 10 桁の形式に変換されます。

音声トランスレーション プロファイルを設定するには、 voice translation-rule および voice translation-profile Cisco IOS コマンドを使用します。これらのコマンドでは、変換の対象となる番号ストリングを正規表現を使用して定義します。次に、この操作を発信番号、着信番号、転送先着信番号のいずれに関連付けるのかを指定します。音声トランスレーション プロファイルを定義したら、次の任意の要素に適用することができます。

• 特定の音声ポート上で終端する、すべての着信 POTS コール レッグ

• ルータに入るすべての着信 VoIP コール レッグ

• 特定の VoIP ダイヤル ピアまたは POTS ダイヤル ピアに関連付けられている発信コール レッグ

• SRST 制御の IP Phone 上で終端する、すべての着信または発信コール レッグ

• SRST 制御のすべての IP Phone によって発信されるコールのための着信コール レッグ

（注） voice translation-rule コマンドを使用する音声トランスレーション プロファイルは、以前に translation-rule コマンドで提供されていた機能を置き換え、拡張するものです。この新しいコマンドの構文は、以前のコマンドで使用されていた構文とは異なります。詳細については、http://www.cisco.com で入手可能な『Cisco IOS Voice Command Reference』（Release 12.2(11)T 以降）の voice translation-rule を参照してください。

音声トランスレーション プロファイルの一般的な用途は、IP WAN が使用不可になっていてルータが SRST モードで動作している場合でも、支店サイトからのオンネット サイト間ダイヤリング手順をそのまま維持できるようにすることです。たとえば、中央サイトが San Jose にあり、3 つのリモート サイトが San Francisco、New York、Dallas にある単純な配置について考えます。 表10-4 では、この例の DID 範囲と内部サイト コードを示しています。

サイト間のコールは、オンネット アクセス コード 8 の次に 1 桁のサイト コードと着信側の 4 桁内線番号をダイヤルすることによって、通常は IP WAN 経由で発生します。IP WAN がダウンしていて Cisco SRST がアクティブな場合にも、これらのダイヤル手順を維持できるようにするには、内部の番号を E.164 番号に再変換してから公衆網に送信する必要があります。次に、San Francisco ルータの設定例を示します。

この設定では、San Francisco サイトが SRST モードになっているときにユーザが 831000 をダイヤルすると、ルータは voice translation-rule 1 の rule 2 と一致するものと判定し、着信番号を 912125551000 に変換します。この新しい番号が使用され、発信ダイヤル ピア（ dial-peer voice 2 ）と一致するものと判定されます。

ダイヤル ピアおよびその設定の詳細については、次の Web サイトで入手可能な『 Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2 』の「 Configuring Dial Plans, Dial Peers, and Digit Manipulation 」を参照してください。

http://www.cisco.com

Cisco IOS の正規表現構文の詳細については、次の Web サイトで入手可能な『 Regular Expressions 』ドキュメントを参照してください。

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7e6.html

マルチサイト配置用の設計ガイドライン

あらゆるマルチサイト IP テレフォニー配置に対して、次のガイドラインとベスト プラクティスが共通して適用されます。複数の Cisco Unified CallManager クラスタが関係する配置については、「分散型コール処理配置に関する追加の考慮事項」の項も参照してください。

• ルーティング ループを防止するには、どの公衆網ゲートウェイのコーリング サーチ スペースにも、外部ルート パターンを含むパーティションが含まれていないことを確認してください。

• 地域通信事業者（LEC）との間で DID 範囲を取り決めるときは、サイト内で重複が発生しない DID 範囲を選択するようにしてください。たとえば、サイト内で 4 桁ダイヤリングを使用していて、1,000 個の DID ブロックが 2 つ必要な場合、ブロック (408)555-1XXX と (408)999-1XXX は 4 桁番号に短縮すると重複し、着信変換と発信変換が実行されるとさらに複雑な状態になります。

• 緊急番号をダイヤルする方法は、複数用意します。たとえば、北米の場合には、911 と 9.911 の両方を Cisco Unified CallManager で緊急ルート パターンとして設定します。

• Automated Alternate Routing（AAR）を配置する場合は、IP Phone 上に設定されている外部電話番号マスクが、各種 AAR グループによって付加されるどのプレフィックスとも競合しないようにする必要があります。たとえば、複数の国にわたる配置の場合、0 などの国内アクセス コードは、それらがグローバル E.164 アドレスの一部でない限り、マスクに含めないでください。

• クラスタ内の宛先に対するオンネット コールを、強制的に公衆網としてダイヤルさせることができます。このためには、各サイトの E.164 DID 範囲に一致するトランスレーション パターンを追加し、このパターンによって、宛先内線番号に一致するように番号を操作します。ただし、適切な AAR を必ず設定してください。次のいずれかの方法を使用して、IP WAN が帯域幅外になったときに自動公衆網フェールオーバーができるようにします。

–「オンネット強制」トランスレーション パターンを含んだパーティションを除外し、公衆網を指す標準ルート パターンを含んだパーティションを含むように、AAR コーリング サーチ スペースを設定します。

–* などの特殊文字をプレフィックスとして番号に付加する AAR グループを設定し、*9.! や *9.!#（または *0.! や *0.!#）などの追加ルート パターンを標準パーティション内に設定します。

2 番目の方法を使用することをお勧めします。この方法では、AAR 用の追加コーリング サーチ スペースを定義する必要がないためです。また、追加の * ルート パターンによって、AAR を呼び出さなくても「オンネット強制」設定を上書きして公衆網経由でコールを発信したり、宛先番号が SRST モードの支店内にあるときに公衆網を通じたコールを強制したりすることができる、AAR 用の優れたトラブルシューティング ツールおよびテスト ツールが提供されるためです。

• N 個のサイトがある集中型コール処理クラスタでは、次のいずれかの方法を使用することで、テールエンド ホップオフ（TEHO）を実装できます。

–集中型フェールオーバーを使用する TEHO

この方法では、N 個のルート パターンをグローバル パーティション内に設定します。各パターンが、適切なリモート サイト ルート グループを最初の選択肢として保持し、中央サイト ルート グループを 2 番目の選択肢として保持しているルート リストを指すようにします。

–ローカル フェールオーバーを使用する TEHO

この方法では、N 個のルート パターンを N セット、サイト固有のパーティション内に設定します。各パターンが、適切なリモート サイト ルート グループを最初の選択肢として保持し、ローカル サイト ルート グループを 2 番目の選択肢として保持しているルート リストを指すようにします。

2 番目の方法では、リモート ゲートウェイや IP WAN が使用不可になった場合に、最も優れたフェールオーバー シナリオを実現できる一方で、ダイヤル プランが非常に複雑になります。最初の方法では、必要になるのは N 個のルート パターンと N 個のルート リストであるのに対して、少なくとも N ² 個のルート パターンと N ² 個のルート リストが必要になるためです。

• 国内の番号計画で許容される場合は、長距離電話としてダイヤルされたローカル公衆網コールを捕捉し、適切な省略形式に変換するための追加トランスレーション パターンを各サイトに設定することをお勧めします。このトランスレーション パターンには、サイト内の電話からのみアクセスできるようにします。このように設定することで、AAR 設定も簡潔化できます（「同じローカル ダイヤリング エリアに複数のサイトがある場合の特別な考慮事項」を参照）。

• Multilevel Precedence and Preemption（MLPP）機能を使用して、緊急コールに高い優先順位を割り当てないでください。緊急時のコールは、IP テレフォニー システムに緊急コールとして表示されない場合もあります。また、メインの緊急サービス ルーティング番号に新たにコールが発信された場合、既存の緊急コールが終了する恐れがあります。たとえば、緊急時に通常の 10 桁の番号へコールを発信し、医療専門家に連絡することが必要になる場合があります。このコールのプリエンプション処理により、進行中の緊急通信が中止され、緊急時の処理が遅延することがあります。また、救急隊員からの着信コールも MLPP でプリエンプション処理される危険性があります。

（注） 多数のゲートウェイ、ルート パターン、トランスレーション パターン、およびパーティションを含む非常に大きなダイヤル プランをもつ CiscoUnified CallManager クラスタでは、Cisco CallManager Service の初回始動時に、初期化に長い時間がかかる場合があります。デフォルトの時間内にシステムが初期化されない場合、サービス パラメータを変更して、設定の初期化時間を延長してください。サービス パラメータの詳細については、Cisco Unified CallManager Administration オンライン ヘルプの「Service Parameters」を参照してください。

分散型コール処理配置に関する追加の考慮事項

分散型コール処理配置（つまり、複数の Cisco Unified CallManager クラスタを含んでいるマルチサイト配置）のダイヤルプランを設計する場合は、前の項で説明した考慮事項に加えて、次のベスト プラクティスに従ってください。

• DID 範囲を複数の Cisco Unified CallManager クラスタにわたって分割することは避けます。分割した場合、経路の集約が不可能になり、クラスタ間ルーティングが非常に困難になります。各 DID 範囲は、それぞれ単一の Cisco Unified CallManager クラスタに配置してください。

• 1 つのリモート サイト内にある複数のデバイスを、静的ロケーションに基づいたコール アドミッション制御を使用して複数の Cisco Unified CallManager クラスタに分割することは避けます。静的ロケーション ベースのコール アドミッション制御が意味を持つのは、1 つのクラスタ内のみです。それぞれ別のクラスタに属している複数のデバイスを同じリモート サイトに配置すると、クラスタ間で使用可能な帯域幅を分割する必要があるため、IP WAN 帯域幅が効率よく使用されなくなります。各リモート サイトは、それぞれ単一の Cisco Unified CallManager クラスタに配置してください。Cisco Unified CallManager 5.0 では、RSVP をロケーションのコール アドミッション制御メカニズムとして設定できるため、単一サイトの合計 WAN 帯域幅を、さまざまなクラスタに属する電話機間で効率よく共有できます。RSVP ベースのコール アドミッション制御を最も効率よく使用するには、リモート サイト内にあるすべての電話機を、Cisco Unified CallManager 5.0 クラスタに設定する必要があります。

• Cisco Unified CallManager クラスタ間でのコール ルーティングには、ゲートキーパー制御クラスタ間トランクを使用します。このようにすると、ネットワーク内でクラスタを簡単に追加および修正できるようになり、他のクラスタをすべて再設定しなくても済みます。

• Cisco Unified CallManager とゲートキーパー間の接続には、冗長性を持たせます。このためには、ゲートキーパー クラスタを使用するか、複数のサーバが設定された Cisco Unified CallManager グループを使用しているデバイス プールに対して、クラスタ間トランクを割り当てます。

• コールをゲートキーパーに送信するときは、着信番号を完全な E.164 アドレスへと展開します。このようにすると、IP WAN が使用不可になった場合の公衆網フェールオーバーが簡単になります。これは、コールを公衆網ゲートウェイ経由で再ルーティングするための追加の番号操作が必要ないためです。また、リモート サイトごとのダイヤル長情報を使用してローカル（発信側）Cisco Unified CallManager を設定する必要がなくなります。

• ゲートキーパー内に、Cisco Unified CallManager クラスタごとにゾーンを 1 つ設定します。クラスタ（ゾーン）ごとに、そのクラスタの所有するすべての DN 範囲に一致するゾーン プレフィックス ステートメントを追加します。

• 次のガイドラインに従うと、複数の Cisco Unified CallManager クラスタにわたってテールエンド ホップオフ（TEHO）を実装することができます。

–関係する E.164 範囲の個々のルート パターンを、送信元（発信元）Cisco Unified CallManager クラスタに追加します。これらのパターンでは、IP WAN ルート グループを最初の選択肢として保持し、ローカル公衆網ルート グループを 2 番目の選択肢として保持するルート リストを指すようにします。

–Cisco IOS ゲートキーパー設定に、関係するすべての E.164 範囲のゾーン プレフィックス ステートメントを追加します。これらのステートメントでは、適切な Cisco Unified CallManager クラスタを指すようにします。

–宛先 Cisco Unified CallManager クラスタに含まれているクラスタ間トランク コーリング サーチ スペースに、ローカル公衆網番号に一致するルート パターンを備えたパーティションを含めます。また、必要に応じて番号操作を適用します（たとえば、コールを公衆網に送信する前にエリア コードを除去します）。

分散型コール処理配置の Cisco IOS ゲートキーパーを設定する方法の詳細については、「ゲートキーパーの設計上の考慮事項」を参照してください。

ダイヤル プラン アプローチの選択

「プランニングの考慮事項」で紹介したように、IP テレフォニー システムの内部宛先用のダイヤル プランには、主に次の 2 つのアプローチがあります。

• 定型オンネット ダイヤル プラン：個々の内部宛先には、発信者が同じサイトにいるか、別のサイトにいるかにかかわらず、同じ方法でダイヤルします。

• 可変長オンネット ダイヤル プラン：内部宛先がサイト内にある場合、複数のサイトにわたっている場合とは別の方法でダイヤルします。通常、サイトの内部でやり取りされるコールの場合は 4 桁または 5 桁の省略ダイヤリングを使用し、複数サイトにわたるコールの場合は、完全な E.164 アドレスを使用するか、オンネット アクセス コード、サイト コード、内線番号をこの順序で使用します。

どちらのアプローチが最適かを判断するには、次の基本的な設計上の質問について検討すると役立ちます。

• IP テレフォニー システムによってサービスされるサイトは、最終的にいくつあるか。

• サイト間または支店間の発信パターンは何か。

• サイト内で、および別のサイトに到達するために、ユーザは何をダイヤルするか。

• オンネットサイト間コールに適用されるコール制限はあるか。

• ほとんどのサイト間コールで使用される転送ネットワークは何か（公衆網または IP WAN）。

• CTI アプリケーションが使用されている場合、それは何か。

• サイト コードを使用して、オンネット ダイヤリング構造を標準化する予定はあるか。

定型オンネット ダイヤル プランは、設計と設定が最も簡単です。ただし、このプランが最も適しているのは中小規模の配置であり、サイトおよびユーザの数が大きくなるほど、実用には適さなくなります。このプランについては、「定型オンネット ダイヤル プランの配置」の項で詳しく説明および分析しています。

可変長オンネット ダイヤル プランは、スケーラビリティが優れていますが、設計と設定も複雑になります。図10-24 では、可変長オンネット ダイヤル プラン アプローチを使用する大規模配置について、一般的な要件を示しています。

図10-24 大規模マルチサイト配置の一般的なダイヤリング要件

Cisco Unified CallManager で可変長オンネット ダイヤル プランを実装する方法には、主に次の 2 つがあります。

• 分割アドレッシング

内部の内線番号は、配置されているサイトに応じて、複数のパーティションに配置します。この方法は、通常はサイト間コールの E.164 アドレスに基づいています。詳細については、「分割アドレッシングを使用する可変長オンネット ダイヤル プランの配置」の項を参照してください。

• フラット アドレッシング

内部の内線番号を、すべて同じパーティションに配置します。この方法は、通常はサイト間コールのオンネット サイト コードに基づいています。詳細については、「フラット アドレッシングを使用する可変長オンネット ダイヤル プランの配置」の項を参照してください。このアプローチは、サイト間コールに完全な E.164 アドレスを使用している場合でも使用できることがあります。「サイト コードを使用しない配置に関する特別な考慮事項」の項を参照してください。

定型オンネット ダイヤル プランの配置

定型オンネット ダイヤル プランを実装するには、次のガイドラインに従います。

• 省略ダイヤルを使用して、すべての電話を一意に識別する。

• すべての電話 DN を単一のパーティションに配置する。

• 各サイトで、選択したサービス クラス アプローチに従って、公衆網ルート パターンを 1 つまたはそれ以上のサイト固有パーティションに配置する。

図10-25 では、単一 Cisco Unified CallManager クラスタ配置での実装例を示しています。

図10-25 定型オンネット ダイヤル プランの配置の例

次の両方の条件に当てはまる場合は、このアプローチを使用します。

• 内部内線番号の識別用に選択した桁数を考慮したとき、使用可能な DID 範囲どうしが重複していない。

• IP テレフォニー システムによって処理されるサイトの数は、長期的に見て大幅に増加することがない。

次の各項では、定型オンネット ダイヤル プランのフレームワークで使用される各種のコールについて、実装の詳細およびベスト プラクティスを分析します。

• 「クラスタ内でのサイト間コール」

• 「発信公衆網コールと IP WAN コール」

• 「着信コール」

• 「ボイスメール コール」

クラスタ内でのサイト間コール

すべての内部 DN に対して、あらゆるデバイスのコーリング サーチ スペースから直接到達することができるため、すべてのオンネット コール（サイト内およびサイト間）が自動的に使用可能になります。Cisco Unified CallManager で特に設定する必要はありません。

発信公衆網コールと IP WAN コール

公衆網コールは、サイト固有のパーティションとルート パターンを使用することで可能になります。このため、緊急コールと市内電話は、ローカルの支店ゲートウェイを通じてルーティングすることができます。長距離電話と国際コールは、企業のポリシーに応じて、同じ支店ゲートウェイを通じてルーティングすることも（図10-25 を参照）、中央ゲートウェイを通じてルーティングすることもできます。この 2 番目の方法で必要になるのは、サイトごとの追加ルート リストのみです。このリストには、中央サイト ゲートウェイを指す第 1 位ルート グループ、およびローカル支店ゲートウェイを指す第 2 位ルート グループ（省略可）を含めます。

別の Cisco Unified CallManager クラスタや Cisco Unified CallManager Express への省略ダイヤリングも、ゲートキーパーを通じて使用できます。これらの IP WAN コールについては、ゲートキーパーに送信する前に、トランスレーション パターンを通じて省略ストリングを完全な E.164 に展開することをお勧めします。

緊急コール

緊急コールの処理に Cisco Emergency Responder を使用する場合は、コールを Cisco Emergency Responder へ送信するために使用される CTI ルート ポイントを含むパーティションを、図10-25 に示したようなサイト固有の 911 パターンではなく、すべての支店内にあるすべての電話機のコーリング サーチ スペースに含める必要があります。内部パーティション内での DN の重複は許容されないので、Cisco Emergency Responder は発信側の電話機を識別できます。Cisco Emergency Responder に関する考慮事項の詳細については、「緊急サービス」の章と、次の Web サイトで入手可能な Cisco Emergency Responder 製品資料を参照してください。

http://www.cisco.com

着信コール

着信公衆網コールで必要となるのは、Cisco Unified CallManager に設定されている内線番号の長さに合せて、余分な桁を除去することのみです。この操作は、ゲートウェイの設定によって、またはゲートウェイのコーリング サーチ スペースに含まれているトランスレーション パターンを通じて実行できます。

ボイスメール コール

各内線番号は、いずれもシステム内部では一意です。したがって、この内線番号を使用してボイスメール システム内にボイスメール ボックスを設定することができます。ボイスメール システムにコールを送信するために、または Cisco Unified CallManager 内のメッセージ待機インジケータ（MWI）をオンにするために、変換を実行する必要はありません。

ただし、ユーザが公衆網からボイスメール システムにアクセスする場合は、ユーザを訓練して、ボイスメール ボックスにアクセスするときに 8 桁の内線番号を入力してもらうようにする必要があります。

分割アドレッシングを使用する可変長オンネット ダイヤル プランの配置

分割アドレッシングを使用する可変長オンネット ダイヤル プランを実装するには、複数のパーティション（サイトごとに 1 パーティション）に分かれている各サイトの電話に対して省略 DN を定義し、グローバル パーティションに含まれている一連のトランスレーション パターン（サイトごとに 1 トランスレーション パターン）を利用して、サイト間コール ルーティングを実行します。

この方法を使用すると、サイトの内部では省略ダイヤリング（通常は 4 桁または 5 桁）をサポートし、サイト間では完全な E.164 ダイヤリングをサポートするという重要な要件を満たすことができます。ただし、ダイヤル プランが複雑になるという代償もあります。

（注） これらの配置は、「重複ダイヤル プラン」または「重複内線番号のあるダイヤル プラン」とも呼ばれます。それぞれのサイトで定義した省略 DN が、通常は互いに重複しているためです。

表10-5 では、各サイトでのコーリング サーチ スペースとパーティションの基本的な関係を示しています。ただし、サービス クラスの実装に必要となる追加の要素は考慮に入れていません。

次の条件に 1 つ以上当てはまる場合は、このアプローチを使用します。

• サイト コードを使用するグローバル オンネット番号計画を使用する予定がない。

（注） このアプローチは、サイト コードを使用するオンネットの内部内線番号計画がある場合にも使用できますが、そのようなシナリオでは、「フラット アドレッシングを使用する可変長オンネット ダイヤル プランの配置」の項で説明しているフラット アドレッシング アプローチに従うことをお勧めします。ダイヤル プランの構造を大幅に簡素化でき、システムの管理とトラブルシューティングが容易になるためです。

• オンネットのサイト間コールに対して、ポリシーによる制約を適用する必要がある（つまり、一部またはすべてのユーザが他のオンネット サイトにダイヤルすることを不許可にする）。

• サイト間コールは、常に公衆網を介してルーティングされる（「集中型コール処理のバリエーションとしての Voice Over the PSTN」の項を参照）。

• CTI ベースのアプリケーションは、サイト間では使用しない。

（注） CTI ベースの一部のアプリケーション（Cisco Emergency Responder など）は、Cisco Attendant Console と同様に重複内線番号をサポートしていないため、分割アドレッシング アプローチを使用して配置することができません。Cisco Personal Assistant や Cisco Unified CallManager Assistant など、その他のアプリケーションは追加のダイヤル プラン設定を必要とします。重複内線番号が存在している場合、このダイヤル プラン設定は複雑なものになり、場合によっては正常に機能しない可能性があります。これらのアプリケーションを配置する予定がある場合は、次の項で説明するフラット アドレッシング アプローチを選択することをお勧めします。

分割アドレッシング アプローチを配置する方法をわかりやすくするために、図10-26 に示す架空の顧客ネットワークについて考えます。このネットワークは、米国内にメイン サイト（San Jose）と多くの小規模支店サイト（New York と Dallas）があり、トポロジは、欧州のメイン サイト（London）と小規模支店サイト（Paris と Milan）に類似しています。ユーザ数、管理上の必要性、およびネットワーク トポロジに基づいて、集中型コール処理を使用する Cisco Unified CallManager クラスタが 2 つ配置されています。1 つは米国で、1 つは欧州です。Cisco IOS ゲートキーパー クラスタを使用して、2 つのクラスタ間での E.164 アドレス解決とコール アドミッション制御を提供しています。可変長オンネット ダイヤル プランが必要なことも決定していて、各サイトの内部では 4 桁ダイヤリングを使用し（各サイトで 1XXX 内線番号範囲を利用）、サイト間では完全な E.164 ダイヤリングを使用します。

図10-26 大規模なマルチサイト配置の例

次の各項では、図10-26 の米国（US）クラスタを例にとって、分割アドレッシング アプローチのフレームワークで使用される各種のコールについて、実装の詳細とベスト プラクティスを分析します。

• 「クラスタ内でのサイト間コール」

• 「発信公衆網コールと IP WAN コール」

• 「着信コール」

• 「ボイスメール コール」

クラスタ内でのサイト間コール

図10-27 では、US クラスタでのサイト間コールの設定例を示しています。

図10-27 分割アドレッシング法におけるクラスタ内部のサイト間コール

サイトとパーティション間の接続性をサポートするために、次のガイドラインに従ってトランスレーション パターンを使用してください。

• サイトごとに 1 つのトランスレーション パターンを定義し、すべてのトランスレーション パターンを Translations_pt パーティションに入れる。

• 各パーティションは、公衆網サイト コード（この例では 9）を含めて、サイトの E.164 アドレス範囲と一致する必要がある。

• 変換後に得られる着信番号は、サイトの内線番号（この例では 1XXX）と一致する必要がある。

• 変換後にコールが送信されるコーリング サーチ スペースには、宛先サイトの IP Phone の DN が入っているパーティションが含まれている必要があります。

発信公衆網コールと IP WAN コール

各種の公衆網コールをどのようにルーティングするかに応じて（集中型ゲートウェイと分散型ゲートウェイ）、設定が異なります。図10-28 の例では、国内公衆網コールはすべてローカル支店ゲートウェイを通じてルーティングされます。国際コールは、欧州クラスタの制御するサイトへのコールを代行受信するために、まずゲートキーパーを通じてルーティングされ、次にローカル公衆網ゲートウェイを通じてルーティングされます。

図10-28 分割アドレッシング法における発信の公衆網コールと IP WAN コール

図10-28 に示すように、発信の公衆網コールと IP WAN コールについては、内部アドレッシングが分割されていても特に考慮事項はありません。

（注） 図10-28 では、従来のアプローチに従ってサービス クラスを構築しています。ただし、回線/デバイス アプローチを分割アドレッシング アプローチと組み合せることもできます。サービス クラス アプローチとエンドポイント アドレッシング アプローチはそれぞれ独立しており、互いを置き換えることはできません。

着信コール

着信の公衆網コールまたは IP WAN コールを適切な内線に送信するには、上記で説明されている Translations_pt パーティション内のトランスレーション パターンを再使用できます。Translations_pt パーティションだけが入っているコーリング サーチ スペースに、すべての公衆網ゲートウェイを割り当て、すでに定義されているトランスレーション パターンと一致させるために、ゲートウェイが、着信ダイヤル番号の前に 9 または 91 をプレフィックスとして付けることを確認するだけで十分です。この方法は、公衆網が各電話機の完全修飾番号をゲートウェイに送信し、着信ダイヤル番号の前に 91 が付いている場合に、Cisco Unified CallManager には Translations_pt パーティションにあるグローバル トランスレーション パターンと一致する番号が渡されることが前提になっています。

ボイスメール コール

ボイスメール統合では、分割アドレッシング アプローチに関する次の要件に特に注意する必要があります。

• ボイスメール ボックスに固有の ID が必要です。つまり、IP Phone の内線番号はボイスメール ボックスとして使用できません。固有の番号を取得するには、番号操作が必要です。

• ボイスメール システムからの MWI（メッセージ待機インジケータ）メッセージは、固有でない内線番号がある場合でも、適切な IP Phone に到達できなければなりません。

最初の項目は、Voice Mail Profile Configuration ページの Voice Mail Box Mask フィールドを使用して、Cisco Unified CallManager で処理されます。このパラメータを設定すると、ボイスメール システムと情報を交換し、ユーザを固有に識別できます。たとえば、Voice Mail Box Mask パラメータをユーザに関連した完全な E.164 番号に設定できます。

2 番目の項目は、オンクラスタ パーティション内のトランスレーション パターンを再使用することによって処理されます。ボイスメール システムが完全な E.164 番号を使用して設定されている場合、以前に Translations_pt パーティションで定義されたトランスレーション パターンと一致させ、適切なサイト間通信を確保するために、E.164 番号の前に 9 を付けることができます。このように、完全な E.164 番号をもつボイスメール システムからの MWI メッセージは、特定のパーティション内の適切な内線番号に変換されます。たとえば、ボイスメール ポートを設定するときに、ボイスメール システムによってダイヤルされる E.164 番号に 9 をプレフィックスとして付加するトランスレーション パターンのみが入った VM_Translations_pt パーティションを含んでいるコーリング サーチ スペースを使用します。このトランスレーション パターンのコーリング サーチ スペースには、Translations_pt パーティションが含まれています。このパーティションによって、定義済みのトランスレーション パターンを通じて、すべての内線番号へのアクセスが提供されます。

（注） このアプローチには、Cisco Unified CallManager 内の 2 つのサービス パラメータの設定が必要です。Cisco CallManager サービス内の MultiTenantMwiMode パラメータを True に設定し、CMI（Cisco Messaging Interface）サービス内の ValidateDNs パラメータを False に設定する必要があります。

フラット アドレッシングを使用する可変長オンネット ダイヤル プランの配置

フラット アドレッシングを使用する可変長オンネット ダイヤル プランを実装するには、電話の DN を、オンネット アクセス コード、サイト コード、および内線番号を含んだ一意のストリング（たとえば、8-123-1000）として定義します。これらの DN を同じグローバル パーティションに配置すると、サイト コードを使用したサイト間コールを使用できるようになり、サイト固有のパーティション内にトランスレーション パターンを定義すると（サイトごとに 1 トランスレーション パターンと 1 パーティション）、サイトの内部では省略ダイヤリングを使用できるようになります。

サイト内でユーザが通常ダイヤルしている 4 桁または 5 桁の番号を使用して、Directory Number 設定ページの Line Text Label パラメータを設定すると、この内部構造をエンドユーザから見えないようにすることができます。AAR を使用可能にし、ユーザが自分の DID 番号を IP Phone のディスプレイで見られるようにするには、外部電話番号マスクについても、対応する公衆網番号を使用して設定する必要があります。

表10-6 では、各サイトでのコーリング サーチ スペースとパーティションの基本的な関係を示しています。ただし、サービス クラスの実装に必要となる追加の要素は考慮に入れていません。

次の条件に 1 つ以上当てはまる場合は、このアプローチを使用します。

• オンネットのサイト間コールで、ダイヤリング制限が必要ない。

• サイト コードを使用するグローバル オンネット番号計画を使用する予定がある。

• サイト間コールは、通常は IP WAN を通じてルーティングされる。

• CTI ベースのアプリケーションをサイト間で使用する。

（注） オンネットのサイト間コールにダイヤリング制限を適用する必要がある場合や、サイト コードを使用するオンネット番号計画を使用する予定がない場合は、それらのニーズに対応可能なこのアプローチの変型について、「サイト コードを使用しない配置に関する特別な考慮事項」の項を参照してください。

このアプローチには、次の考慮事項が適用されます。

• サイト内の 4 桁コールの宛先番号は、IP Phone のディスプレイでは一意の内部 DN へと展開されます。

• Placed Calls ディレクトリでは、ユーザがダイヤルしたとおりに元の 4 桁のストリングが表示されます。

• 発信番号、および Missed Calls ディレクトリと Received Calls ディレクトリの番号は、一意の内部 DN として表示されます。

• IP WAN が使用不可になって支店の電話が SRST モードになっている場合でも、4 桁ダイヤリング機能をそのまま使用できるようにするには、SRST ルータの call-manager-fallback 設定に変換規則を適用する必要があります。

• 支店の電話が SRST モードになっている場合、一意の内部 DN を IP Phone のディスプレイ上で 4 桁番号としてマスクする Line Text Label は、使用できません。代わりに、ユーザには完全な内部 DN が表示されます。

フラット アドレッシング アプローチを配置する方法をわかりやすくするために、図10-26 に示す架空の顧客ネットワークについてもう一度考えます。この場合、可変長オンネット ダイヤル プランが必要になることは決定していて、各サイトの内部では 4 桁ダイヤリングを使用し（各サイトで 1XXX 内線番号範囲を利用）、サイト間のダイヤリングでは、オンネット アクセス コード（この例では 8）、3 桁のサイト コード、および 4 桁の内線番号で構成される 8 桁のストリングを使用します。3 桁のサイト コードは、米国にあるサイトの場合は NANP エリア コードから生成され、欧州にあるサイトの場合は E.164 国コードとサイト識別子から生成されます。 表10-7 では、選択されたサイト コードを示しています。

次の各項では、この例の US クラスタを使用して、フラット アドレッシング アプローチのフレームワークで使用される各種のコールについて、実装の詳細とベスト プラクティスを分析します。

• 「クラスタ内でのサイト間コール」

• 「発信公衆網コールと IP WAN コール」

• 「着信コール」

• 「ボイスメール コール」

• 「サイト コードを使用しない配置に関する特別な考慮事項」

クラスタ内でのサイト間コール

図10-29 では、US クラスタでのサイト間コールの設定例を示しています。

図10-29 フラット アドレッシング法におけるクラスタ内部のサイト間コール

サイトとパーティション間の接続性をサポートするために、次のガイドラインに従ってください。

• オンネット アクセス コード 8 を含めて、一意の DN をすべてグローバル パーティション（この例では Internal_pt）に配置します。

• サイトごとにパーティションを 1 つ作成し、それぞれのパーティションの中に、4 桁番号をそのサイトの完全修飾 8 桁番号に展開するトランスレーション パターンを配置して、サイト内部で省略ダイヤリングを使用できるようにします。

• 各サイトで、Internal_pt パーティションとローカル トランスレーション パーティションの両方を電話のコーリング サーチ スペースに含めます。

Cisco Unified CallManager に設定されている DN にオンネット アクセス コードを含めると、すべての電話から直接アクセスできるパーティションの中にすべての内部内線番号を配置できるようになり、同時に、IP Phone 上のすべてのコール ディレクトリの中に、直接にリダイヤル可能な番号が確実に入力されます。

（注） ただし、オンネット アクセス コードとサイト コードの組み合せが、どのサイトのローカル省略ダイヤリング範囲とも重複しないようにする必要があります。

発信公衆網コールと IP WAN コール

各種の公衆網コールをどのようにルーティングするかに応じて（集中型ゲートウェイと分散型ゲートウェイ）、設定が異なります。

欧州（EU）クラスタへのサイト間コールに対してオンネット接続を提供するには、次のオプションがあります。

オプション 1：8 桁番号のみ

このオプションでは、単一のルート パターンを利用します。このパターンはすべての 8 桁範囲（8XXXXXXX）に一致し、ゲートキーパー制御クラスタ間トランクのみを含んだルート リストまたはルート グループを指しています。ゲートキーパーは、サイト コードをゾーン プレフィックスとして使用するように設定します。

このソリューションは、他のクラスタのサイト コードや E.164 範囲に関する情報が必要ないため、簡潔で保守が容易です。ただし、IP WAN が使用不可になった場合、自動公衆網フェールオーバーは提供されません。ユーザは、公衆網アクセス コードと宛先の E.164 アドレスを使用して、手動で再ダイヤルする必要があります。

オプション 2：8 桁番号と E.164 アドレス（集中型公衆網フェールオーバーを使用）

このオプションでは、図10-30 に示すように、欧州の 8 桁範囲に一致し、それらを対応する E.164 番号に変換するグローバルな一連のトランスレーション パターンを使用します。これらのトランスレーション パターンでは、中央サイト（この場合は San Jose）のコーリング サーチ スペースを使用するので、コールは中央サイトの公衆網パーティションにある国際公衆網ルート パターンに一致します。各サイトの国際公衆網ルート パターンは、IP WAN ルート グループを最初の選択肢として保持し、ローカル公衆網ルート グループを 2 番目の選択肢として保持しているルート リストを指しています。ゲートキーパーは、E.164 アドレスをゾーン プレフィックスとして使用するように設定します。

図10-30 IP WAN コールに集中型公衆網フェールオーバーを使用する、フラット アドレッシング法における発信の公衆網コールと IP WAN コール

（注） 図10-30 の設定例は、サービス クラスを構築するための回線/デバイス アプローチが使用されていることを前提としています。ただし、従来のアプローチを使用する場合も同じ考慮事項が適用されます。

このソリューションは、オプション 1 で説明したソリューションよりもわずかに設定および保守作業が増えます。これは、他のクラスタのサイト コードと E.164 範囲に関する情報を設定し、保守する必要があるためです。その一方で、IP WAN が使用不可になった場合には、自動公衆網フェールオーバーが提供されます。公衆網フェールオーバーは、中央サイトのゲートウェイのみを使用して提供されます。このため、IP WAN 帯域幅の使用効率は最適なものにはなりません。

また、公衆網コールとしてダイヤルされた欧州サイトへのコールは、IP WAN が使用可能な場合、ローカル ゲートウェイを使用する自動公衆網フェールオーバーによって、自動的にオンネットになります。

オプション 3：8 桁番号と E.164 アドレス（分散型公衆網フェールオーバーを使用）

このオプションでは、図10-31 に示すように、サイトごとに一連のトランスレーション パターンを使用します。各セットは、欧州の 8 桁範囲に一致し、それらを対応する E.164 番号に変換します。これらのトランスレーション パターンでは、発信元サイトのコーリング サーチ スペースを使用するので、コールは発信元サイトの公衆網パーティションにある国際公衆網ルート パターンに一致します。各サイトの国際公衆網ルート パターンは、IP WAN ルート グループを最初の選択肢として保持し、ローカル公衆網ルート グループを 2 番目の選択肢として保持しているルート リストを指しています。ゲートキーパーは、E.164 アドレスをゾーン プレフィックスとして使用するように設定します。

図10-31 IP WAN コールに分散型公衆網フェールオーバーを使用する、フラット アドレッシング法における発信の公衆網コールと IP WAN コール

このソリューションは、オプション 2 で説明したソリューションよりも設定および保守作業がかなり増えます。これは、他のクラスタのサイト コードと E.164 範囲に関する情報を設定し、保守して、クラスタ内の各リモート サイトでこの設定作業を繰り返す必要があるためです。その一方で、IP WAN が使用不可になった場合には、ローカル サイトのゲートウェイを使用して自動公衆網フェールオーバーが提供されるため、IP WAN 帯域幅の使用効率は最適なものになります。

このソリューションでも、公衆網コールとしてダイヤルされた欧州サイトへのコールは、IP WAN が使用可能な場合、ローカル ゲートウェイを使用する自動公衆網フェールオーバーによって、オプション 2 と同様に自動的にオンネットになります。

着信コール

着信公衆網コールでは、8 桁の内部番号を取得して宛先の電話に到達するには、E.164 番号を操作する必要があります。この要件は、次の方法のいずれかで満たすことができます。

• Cisco Unified CallManager の Gateway Configuration ページにある Num Digits フィールドと Prefix Digits フィールドを設定して、必要な番号を除去してプレフィックスを付加するようにします。

• クラスタ内でオンネット サイト間コールを強制するトランスレーション パターンを設定した場合は、公衆網アクセス コードをゲートウェイ上の着信番号にプレフィックスとして付加するだけで、それらのパターンを再利用することができます。

• H.323 ゲートウェイを使用している場合は、コールを Cisco Unified CallManager に送信する前に、ゲートウェイ内の変換規則を使用して番号を操作できます。

3 番目のアプローチは、支店が SRST モードになっている場合、設定済みの変換規則を再利用して IP Phone に着信公衆網接続を提供できる利点があります。

ボイスメール コール

8 桁の各内線番号は、いずれもシステム内部では一意です。したがって、この内線番号を使用してボイスメール システム内にボイスメール ボックスを設定することができます。ボイスメール システムにコールを送信するために、または Cisco Unified CallManager 内のメッセージ待機インジケータ（MWI）をオンにするために、変換を実行する必要はありません。ユーザは、メールボックス番号の入力を求められたときに、8 桁のオンネット番号を使用する必要があることに注意してください。

サイト コードを使用しない配置に関する特別な考慮事項

このシナリオは、フラット アドレッシング アプローチの変型であり、サイト コードに基づいてオンネット番号計画を定義することに依存しません。このシナリオでは、サイト内コールは 4 桁番号としてダイヤルします。その一方で、サイト間コールは通常の公衆網コールとしてダイヤルするため、コールは Cisco Unified CallManager によって代行受信され、IP WAN を通じてルーティングされます。

このメカニズムを実装するには、図10-32 に示すように、次のガイドラインに従います。

• 電話 DN は、完全な E.164 アドレスとして定義し、すべて同じパーティション（この例では Internal_pt）に配置します。

• 電話のコーリング サーチ スペースは、Internal_pt パーティションに直接アクセスできないように設定します。代わりに、Global_Translation_pt というグローバル パーティションを指すようにします。このパーティションには、サイトごとに 1 パーティション、または DID 範囲を含めます。

• 公衆網アクセス コードと国コード（たとえば 91）を除去するトランスレーション パターンを設定し、コールを Hidden_css コーリング サーチ スペースを通じて Internal_pt パーティションに送信します。

• 各サイトの内部では、トランスレーション パターン（サイトごとに 1 パーティションと 1 トランスレーション パターン、または DID 範囲）を含んだサイト固有のパーティションを通じて、省略 4 桁ダイヤリングを提供できます。

図10-32 サイト コードを使用せずにフラット アドレッシングを使用する可変長ダイヤル プラン

この応用設定では、サイト間コールにダイヤリング制限を課すことができます。たとえば、あるユーザ グループが他のサイトにコールすることを禁止する必要がある場合は、そのグループのコーリング サーチ スペースに Global_Translation_pt パーティションを含めないようにします。ただし、このアプローチを選択する場合は次の要素に注意してください。

• トランスレーション パターンの形式が、さらに複雑になります。

• 実質上オンネット公衆網コールを強制することになるため、AAR を設定して、IP WAN の帯域幅が十分にない場合でも公衆網経由でコールを発信できるようにしてください。詳細については、「マルチサイト配置用の設計ガイドライン」を参照してください。

• 「発信履歴」ディレクトリには、ユーザがダイヤルしたとおりに番号ストリングが表示されます。たとえば、ユーザが 1000 をダイヤルして電話機 4085551000 へのコールが発信された場合、「発信履歴」のディレクトリには 1000 が表示されます。これにより、ダイヤル ストリングを編集しなくても番号を直接リダイヤルできます。

• 「不在履歴」と「発信履歴」のディレクトリには、電話機にコールが提供されたときに表示されたとおりの電話番号が表示されます。提供される発信番号は、トランスレーション パターンの Calling Number の設定パラメータと、発信側電話機の回線設定によって異なります。

• 図10-32 に示した設定では、公衆網コールがすべてのサイトで同じ方法によってダイヤルされることを前提としています。単一の国内で閉じている配置は、通常はこの条件を満たしています。複数の国にわたる配置では、サイト間コールを代行受信するために、国ごとに一連の追加トランスレーション パターンが必要です。

• 複数の国にわたる配置では、可変長の内部 DN を取り扱うという複雑さもあります。E.164 アドレスは、国によって（場合によっては、1 つの国の中でも）長さが異なるためです。

Cisco Unified CallManager 5.0 を使用する電話機でのダイヤル パターン認識の配置

SIP 電話機のダイヤル パターン認識機能では、企業内のユーザから予測される一般的なダイヤリングの傾向を考慮する必要があります。一般に、ほとんどの企業では次のパターンの組み合せが使用されます。

• 同じサイト内でのコールのための省略ダイヤリング パターン（定型オンネット ダイヤル プランの場合、省略ダイヤリング パターンがサイト間コールに使用される場合があります）

• サイト コードとオンネット アクセス コード（たとえば 8）を使用しているときに可変オンネット ダイヤル プランで一般的に使用されるサイト間ダイヤリング パターン

• ローカル コール用のオフネット ダイヤリング パターン

• 長距離コール用のオフネット ダイヤリング パターン

• 緊急コール パターン（オフネット アクセス コードありとなし）

• 国際コール用のオフネット ダイヤリング パターン

表10-8 と 表10-9 は、次のダイヤル プラン特性を持つ企業で採用できる SIP ダイヤル規則の例を示しています。

• 省略ダイヤリングは 4 桁（サイト間コールに省略ダイヤリングが使用されるかどうかは無関係）

• サイト間コールではオンネット アクセス コードとして 8 を使用し、その後にサイト コードと DN を表す 7 桁が続く

• 緊急ダイヤリングは 911 および 9911 として許可

• ローカルの 7 桁コールでは 9 をオフネット アクセス コードとして使用し、その後に 7 桁が続く

• ローカルの 10 桁コールはで 9 をオフネット アクセス コードとして使用し、その後に 10 桁が続く

• 長距離コールは 91 と 10 桁をダイヤル

• 国際コールは、9011 の後に不定の桁数が続き、ダイヤリングを # で終了可能

パターン認識は、桁間タイムアウトや Dial キー操作の必要なく、Cisco Unified CallManager に自動的に転送されるユーザ番号入力の収集の自動化だけに関係しています。サービス クラスの実施はすべて、Cisco Unified CallManager の中から選択された各種のコーリング サーチ スペースによって処理されます。すべての電話機を SIP ダイヤル規則を使用して設定し、たとえば、一部の電話機に無制限のサービス クラスが割り当てられていなくても国際ダイヤリングを認識できるようにするのは、その理由からです。

上記のダイヤル プラン特性は、フラット アドレッシングを使用する代表的な可変長オンネット ダイヤル プランです（「フラット アドレッシングを使用する可変長オンネット ダイヤル プランの配置」を参照）。パターン認識の観点から見ると、このダイヤル プランは、定型オンネット ダイヤル プラン、および分割アドレッシングを使用する可変長オンネット ダイヤル プランと互換性があります（「定型オンネット ダイヤル プランの配置」および 「分割アドレッシングを使用する可変長オンネット ダイヤル プランの配置」を参照）。

表10-8 と 表10-9 の各パターンに対して、同等の Cisco Unified CallManager 表記のパターンを示してあります。これらの表は、7905_7912 と 7940_7960_OTHER の両方のケースについて、SIP ダイヤル規則を示しています。

（注） 7905_7912 の SIP ダイヤル規則は 128 文字までに制限され、7940_7060_OTHER の SIP ダイヤル規則は 8K（8,192）文字までに制限されています。

従来のアプローチによる Cisco Unified CallManager のサービス クラスの構築

Cisco Unified CallManager では、次のようにパーティションおよびデバイス コーリング サーチ スペースを外部ルート パターンと組み合せると、IP テレフォニー ユーザにサービス クラスを定義することができます。

• 外部ルート パターンをコール可能な宛先に関連したパーティションに置きます。1 つのパーティションにすべてのルート パターンを含めることができますが、コール可能な宛先に応じてルート パターンをパーティションに関連付けると、より高度なコール制限ポリシーを実現できます。たとえば、同じパーティションにローカル ルート パターンと国際ルート パターンを入れる場合、すべてのユーザは、ローカルの宛先と海外の宛先の両方と通信できます。ただし、これは好ましくない場合があります。ルート パターンは、さまざまなサービス クラスの到達可能性ポリシーに従って、それぞれのパーティションに分類することをお勧めします。

• 各コーリング サーチ スペースがそのコール制限ポリシーに関連したパーティションのみに到達できるように設定します。たとえば、ローカル コーリング サーチ スペースが内部パーティションとローカル パーティションを指定するように設定します。その結果、このコーリング サーチ スペースに割り当てられるユーザは、内部コールおよびローカル コールしか発信できません。

• Cisco Unified CallManager のデバイス ページで電話機を設定して、これらのコーリング サーチ スペースを電話機に割り当てます。このように設定すると、デバイス上に設定されているすべての回線が自動的に同じサービス クラスを受信します。

図10-33 では、単純な単一サイト配置の例を示しています。

図10-33 従来のアプローチを使用するサービス クラスの基本的な例

このアプローチでは、デバイス コーリング サーチ スペースが次の 2 つの論理機能を実行します。

• パスの選択

コーリング サーチ スペースは、特定のパーティションを含んでいます。このパーティションは、ルート リストとそれに関連したルート グループを通じて、特定の公衆網ゲートウェイを指している特定のルート パターンを含んでいます。

• サービス クラス

特定のパーティションのみをデバイス コーリング サーチ スペースに含めて、他のパーティションを含めないようにすると、特定のユーザ グループに対して実質上のコール制限が適用されます。

結果として、このアプローチを集中型コール処理のマルチサイト配置に適用する場合は、パーティションとコーリング サーチ スペースを各サイトに複製する必要があります。これは、図10-34 に示すように、サイトごとにサービス クラスを作成し、同時に、ローカル支店ゲートウェイから発信される公衆網コールをルーティングする必要があるためです。

図10-34 従来のアプローチで必要となるコーリング サーチ スペースとパーティション

集中型コール処理を使用するマルチサイト配置に対してこのダイヤル プラン アプローチを適用する場合は、さらに次のガイドラインに従ってください。

• サイト間のオンネット ダイヤリングを構成するために、すべての IP Phone の DN をすべてのサイトのコーリング サーチ スペースからアクセス可能なオンクラスタまたは内部のパーティションに置きます。これは、IP Phone の DN が重複している場合は不可能であることに注意してください。重複内線番号を使用するダイヤル プランの詳細については、「分割アドレッシングを使用する可変長オンネット ダイヤル プランの配置」を参照してください。

• 各リモート サイトに、独自のパーティションとルート パターンのセットを指定します。リモート サイトごとのパーティション数は、ルート パターンに関連したコール制限ポリシー数によって異なります。

• 各サイトに、そのサイトの IP Phone 用に独自のコーリング サーチ スペースのセットを指定します。このコーリング サーチ スペースは、適切なローカル ルート パターン パーティションと共に、オンクラスタ パーティションも指定します。

• 企業の自動転送制限ポリシーによっては、サイト固有のデバイス コーリング サーチ スペースの 1 つを Forward All コーリング サーチ スペースに再利用することができます。

必要なコーリング サーチ スペースの合計数とパーティションの合計数を計算するには、通常は次の公式を使用してください。

合計パーティション数 = （サービス クラス数） ∗ （サイト数） + （すべての IP Phone の DN 用に 1 パーティション）

合計コーリング サーチ スペース数 = （サービス クラス数） ∗ （サイト数）

（注） これらの値は、最低限必要となるパーティション数とコーリング サーチ スペース数を表しています。特殊なデバイスやアプリケーションには、他のコール処理エージェント用のオンネット パターンと同様に、追加のパーティションやコーリング サーチ スペースが必要になることがあります。

従来のアプローチにおけるエクステンション モビリティの考慮事項

エクステンション モビリティ機能を使用する場合、電話機のダイヤル制限は、その電話機へのログイン（またはログアウト）中の機能の 1 つになります。ログアウトされた電話機は、他の電話機やサービス（たとえば、米国では 911）のコールを制限する必要があります。一般に、公衆網を通じた市内または市外通話へのアクセスは制限されます。逆に、ユーザがログインしている電話機は、そのユーザのダイヤリング権限に応じてコールを許可し、それらのコールを適切なゲートウェイ（たとえば、同じ場所に配置されているローカル コール用の支店ゲートウェイ）にルーティングする必要があります。

エクステンション モビリティを使用する場合、サービス クラスを構築するための従来のアプローチでコール制限を適用するには、次のガイドラインを考慮してください。

• 各サイトで、すべての IP Phone のデバイス コーリング サーチ スペースを、公衆網緊急サービスのみを（ローカル ゲートウェイを使用して）指すように設定します。

• エクステンション モビリティに使用される IP Phone がログアウト状態になっている場合の回線コーリング サーチ スペースを、内部番号のみを指すように設定します。

• 各エクステンション モビリティ ユーザについて、デバイス プロファイル内の回線コーリング サーチ スペースを、個々のユーザのサービス クラスで許可されている内部番号と追加公衆網ルート パターンを（ここでも、企業ポリシーに従って適切なゲートウェイを使用して）指すように設定します。

通常はサイト 1 を拠点としているエクステンション モビリティ ユーザが、サイト 2 の IP Phone にログインすると、公衆網コールのパス選択が次のように変更されます。

• 緊急コールは、サイト 2 の公衆網ゲートウェイを使用して正しくルーティングされます。緊急サービスは、サイト 2 にある IP Phone のデバイス コーリング サーチ スペースによって提供されるためです。

• この他のすべての公衆網コールは、エクステンション モビリティ ユーザのプロファイル（具体的には、デバイス プロファイル内に設定されている回線コーリング サーチ スペース）に従ってルーティングされます。これは、通常、これらの公衆網コールが 2 つの WAN リンクを通過し、サイト 1 のゲートウェイを使用して公衆網にアクセスすることを意味します。

この動作を修正し、エクステンション モビリティ ユーザが別のサイトにローミングしている場合でも、公衆網コールが常にローカル公衆網ゲートウェイを通じてルーティングされるようにするには、次のいずれかの方法を使用します。

• ローカル公衆網ルート パターンは、デバイス コーリング サーチ スペースに含めて、デバイス プロファイル内の回線コーリング サーチ スペースからは削除します。この方法によって、ローカルの公衆網コールは、同じ場所にある支店ゲートウェイを通じてルーティングされるようになります。ただし、同時に、ユーザは IP Phone にログインしなくてもこれらのコールをダイヤルできるようになります。長距離電話と国際コールについては、エクステンション モビリティ ユーザのデバイス プロファイルに従ってルーティングされます。したがって、このソリューションが適しているのは、通常これらのコールが中央ゲートウェイを通じてルーティングされている場合のみです。

• 各ユーザに対して、ユーザがローミングするサイトごとに 1 つずつ、複数のデバイス プロファイルを定義します。各デバイス プロファイルの設定では、回線コーリング サーチ スペースが、そのサイトのローカル ゲートウェイを使用する公衆網ルート パターンを指すようにします。ローミングするユーザおよびローミング先となるサイトが非常に多い場合、この方法は設定と管理の負荷が大きくなります。

• 次の項（「回線/デバイス アプローチによる Cisco Unified CallManager のサービス クラスの構築」）で説明する回線/デバイス アプローチを実装します。

（注） Cisco Emergency Responder を使用する場合は、デバイスに設定するサイト固有のコーリング サーチ スペースに、Cisco Emergency Responder を指す 911 CTI ルート ポイントを含むパーティションを含める必要があります。その同じパーティションに、同じ 911 CTI ルート ポイントを指すトランスレーション パターン 9.911 も含めると、ユーザは 9911 をダイヤルして救急サービスに連絡することができます。

回線/デバイス アプローチによる Cisco Unified CallManager のサービス クラスの構築

前の項で説明した従来のアプローチは、集中型コール処理を使用した大規模なマルチサイト配置に適用する場合、結果的にパーティションとコーリング サーチ スペースの数が非常に多くなることがあります。このような構成にする必要があるのは、デバイス コーリング サーチ スペースを使用して、パス選択（外部コールにどの公衆網ゲートウェイを使用するか）とサービス クラスの両方を決定しているためです。

これらの 2 つの機能を回線コーリング サーチ スペースとデバイス コーリング サーチ スペースに分配すると、必要となるパーティションとコーリング サーチ スペースの総数を大幅に減らすことができます。この手法を「回線/デバイス アプローチ」と呼びます。

所定の各 IP Phone の回線コーリング サーチ スペースとデバイス コーリング サーチ スペースが Cisco Unified CallManager でどのように組み合されているか、および回線コーリング サーチ スペースのパーティションが、結果のコーリング サーチ スペースでどのようにして最初に表示されるのか（「Cisco Unified CallManager におけるコール特権」を参照）に注目すると、回線/デバイス アプローチでは、一般に次の規則を適用できます。

• デバイス コーリング サーチ スペースは、コール ルーティング情報（たとえば、どのゲートウェイを公衆網コール用に選択するか）を提供するために使用します。

• 回線コーリング サーチ スペースは、サービス クラス情報（たとえば、どのコールを許可するか）を提供するために使用します。

これらの規則がどのように適用されるのかをわかりやすくするために、図10-35 に示す例について考えます。このデバイス コーリング サーチ スペースは、国際番号を含めて、すべての公衆網番号へのルート パターンが入ったパーティションを保持しています。このルート パターンは、ルート リストおよびルート グループを通じて、公衆網ゲートウェイを指しています。

図10-35 回線/デバイス アプローチにおける重要な概念

同時に、回線コーリング サーチ スペースは、トランスレーション パターンが 1 つのみ入ったパーティションを保持しています。このパターンは国際番号に一致し、ブロック パターンとして設定されています。

したがって、結果のコーリング サーチ スペースには、国際番号に一致する 2 つの同一パターンが保持されています。最初に表示されるのは、回線コーリング サーチ スペースに含まれているブロック パターンです。結果として、この回線からの国際通話はブロックされます。

回線コーリング サーチ スペースでは、トランスレーション パターンの代わりに、ルート パターンを使用してコールをブロックすることもできます。ブロック ルート パターンを設定するには、まず、使用されていない IP アドレスを使用して「ダミー」ゲートウェイを作成し、そのゲートウェイを「ダミー」ルート リストおよびルート グループに配置します。次に、ダミー ルート リストを指すようにルート パターンを設定します。コールをブロックするルート パターンとトランスレーション パターンの主な違いは、ブロックされている番号をエンドユーザがダイヤルしようとしたときの対応です。次に例を示します。

• トランスレーション パターンを使用した場合、エンドユーザは番号を最後までダイヤルできます。ダイヤルが完了した時点でのみ、ユーザにファースト ビジー トーンが再生されます。

• ルート パターンを使用した場合は、エンドユーザのダイヤルしている番号が許可パターンに一致する可能性がなくなると、その時点ですぐにファースト ビジー トーンが再生されます。この動作は、SCCP を実行している IP Phone、または SIP を実行し、電話機に SIP ダイヤル規則が設定されていないタイプ B の IP Phone を前提にしています。

集中型コール処理を使用するマルチサイト配置に対して回線/デバイス アプローチを実装する場合は、さらに次のガイドラインに従ってください。

• サイトごとに無制限のコーリング サーチ スペースを作成し、電話機のデバイス コーリング サーチ スペースに割り当てます。このコーリング サーチ スペースには、電話機のロケーションに適したゲートウェイ（たとえば、同じ場所に配置されている緊急サービス用の支店ゲートウェイと、長距離電話用の中央ゲートウェイ）にコールをルーティングするルート パターンを備えたパーティションが含まれていなければなりません。

• ユーザのダイヤリング権限に含まれていないタイプのコールに対するブロック トランスレーション/ルート パターンを備えたパーティションを含むコーリング サーチ スペースを作成し、ユーザの回線に割り当てます。たとえば、ユーザが国際コール以外のすべてのタイプのコールを利用できる場合、そのユーザの回線は、9.011! ルート パターンをブロックするコーリング サーチ スペースを使用して設定する必要があります。

図10-36 は、N 個のサイトがあるマルチサイト配置に対して、これらのガイドラインを適用する方法の例を示しています。

図10-36 回線/デバイス アプローチで必要となるコーリング サーチ スペースとパーティション

この方法の利点として、サイトごとに必要なサイト固有の無制限コーリング サーチ スペースが支店に 1 つのみであるという点があります。ダイヤリング権限は、ブロック ルート パターン（サイトに依存しない）の使用により実装されるので、同じセットのブロック コーリング サーチ スペースをすべての支店で使用できます。

結果として、必要なコーリング サーチ スペースの合計数とパーティションの合計数を計算するには、次の公式を使用できます。

合計パーティション数 = （サービス クラス数） + （サイト数） + （すべての IP Phone の DN 用に 1 パーティション）

合計コーリング サーチ スペース数 = （サービス クラス数） + （サイト数）

（注） これらの値は、最低限必要となるパーティション数とコーリング サーチ スペース数を表しています。特殊なデバイスやアプリケーションには、他のコール処理エージェント用のオンネット パターンと同様に、追加のパーティションやコーリング サーチ スペースが必要になることがあります。

（注） Cisco Emergency Responder を使用する場合は、911 CTI ルート パターンと 9.911 トランスレーション パターンをグローバルな On-Cluster パーティションに含めることができます。

サイトの数が多い集中型コール処理配置に対して回線/デバイス アプローチを適用すると、必要となるパーティションとコーリング サーチ スペースの数が大幅に減少します。たとえば、100 のリモート サイトと 4 つのサービス クラスがある配置の場合、従来のアプローチでは、少なくとも 401 のパーティションと 400 のコーリング サーチ スペースが必要です。回線/デバイス アプローチでは、105 のパーティションと 104 のコーリング サーチ スペースしか必要ありません。

ただし、回線/デバイス アプローチが成立するのは、特定サービス クラスの使用を制限する必要のある公衆網コールのタイプ（たとえば、市内電話、長距離電話、国際コール）を、グローバルに識別できる場合です。使用している国の国内番号計画が原因で、コール タイプをグローバルに識別することができない場合、このアプローチの効果は、（設定の省力化に関しては）上の公式に示したものよりも小さくなります。

たとえば、フランスでは、番号計画は 5 桁のエリア コード（01 ～ 05、および携帯電話の 06 エリア コード）に基づいており、この後に 8 桁の加入者番号が続きます。ここで重要となる特徴は、各公衆網宛先に到達するとき、同じローカルエリアからコールするときも、別のエリアからコールするときも、必ず同じ番号（たとえば、Paris の番号は 01XXXXXXXXX、Nice の番号は 02XXXXXXXXX など）をダイヤルすることです。つまり、「長距離電話」であるかどうかは、発信者がどのエリアにいるかに応じて変化します。このため、1 つのパーティションと 1 つのルート パターンでは、長距離電話へのアクセスをブロックできません。たとえば、発信者が Paris にいる場合、014455667788 へのコールは市内電話ですが、発信者が Nice や Lyon にいる場合は長距離電話です。

このような場合は、市内電話と長距離電話が同じ方法でダイヤルされるエリアごとに 1 つずつ、一連のブロック用コーリング サーチ スペースとパーティションを追加設定する必要があります。フランスの例では、 表10-10 に示すように、各エリア コードに対して 1 つずつ、5 組のブロック用コーリング サーチ スペースとパーティションを追加で定義する必要があります。

回線/デバイス アプローチのガイドライン

Cisco Unified CallManager 5.0 では、回線設定ページに Secondary Calling Search Space for Forward All が新たに導入されました。このコーリング サーチ スペースが回線の Forward All コーリング サーチ スペースと連結されることにより、回線/デバイス ダイヤル プラン アプローチを使用して、Forward All 動作に同じ回線から発信される通常のコールと同じサービス クラスを提供できます。連結の順序は、Forward All コーリング サーチ スペースが先で、その後に Secondary Calling Search Space for Forward All が続きます。

回線/デバイス アプローチを使用する場合は、次のガイドラインを考慮してください。

• Forward Busy および Forward No Answer のコーリング サーチ スペースは、回線またはデバイスのコーリング サーチ スペースと連結されません。

• Forward Busy および Forward No Answer コーリング サーチ スペースは、ボイスメール パイロット番号およびポートに到達できる、グローバル コーリング サーチ スペースに設定します。

• Forward All コーリング サーチ スペースは、企業のポリシーに従って設定します。

–転送コールが無制限の特権を持つ必要がある場合は、サイト固有のデバイス コーリング サーチ スペースに一致するように Forward All コーリング サーチ スペースを設定します（エクステンション モビリティを使用する場合の追加の考慮事項については、「回線/デバイス アプローチにおけるエクステンション モビリティの考慮事項」を参照）。

–転送コールを内部番号のみに制限する必要がある場合は、Forward All コーリング サーチ スペースを、内部番号にのみ到達可能なグローバル コーリング サーチ スペースに設定します。

–転送されるコールを通常のコールと同じサービス クラスにする必要がある場合は、回線に設定したものと同じコーリング サーチ スペースを Forward All に設定し、デバイスに設定したサイト固有のコーリング サーチ スペースを Secondary Calling Search Space for Forward All に設定します。

（注） SIP を実行するタイプ A の IP Phone は、電話機から開始される Rerouting Calling Search Space for Forward All 動作を使用します。Cisco Unified CallManager のユーザ ページまたは管理ページから開始される Forward All 動作は、上記の連結されたコーリング サーチ スペースを使用します。

（注） Cisco Unified CallManager 5.0 より前のバージョンで、転送コールに中間的な制限を適用する必要がある場合は（ローカル公衆網番号へのアクセスに適用し、国際番号には適用しないなど）、サイト固有の追加のコーリング サーチ スペースが必要になるため、回線/デバイス アプローチの効果は小さくなります。このような場合は、従来のアプローチを選択することをお勧めします。

• このアプローチが機能するには、回線コーリング サーチ スペース内に設定するブロック パターンの詳細度が、デバイス コーリング サーチ スペース内に設定したルート パターンと少なくとも同等になっている必要があります。エラーが発生することを避けるために、ブロックの対象となるパターンは、可能な場合にはルーティングを許可するパターンよりも詳細に設定することをお勧めします。@ ワイルドカード内に定義されるパターンは非常に詳細なものになるため、このワイルドカードの取り扱いには十分に注意してください。

• オンネット DN がダイヤルされると、AAR が呼び出されます。これらの DN へのアクセスは、上で説明したものと同じプロセスで制御できます。AAR は、再ルーティングされるコールには別のコーリング サーチ スペースを使用します。ほとんどの場合、AAR コーリング サーチ スペースは、サイト固有の無制限デバイス コーリング サーチ スペースと同じものでかまいません。このコーリング サーチ スペースは、エンドユーザによって直接ダイヤルされることがないためです。

（注） 回線とデバイスの優先順位は、CTI デバイス（CTI ルート ポイントと CTI ポート）に関しては逆になります。これらのデバイスの場合、結果のコーリング サーチ スペースでは、デバイス コーリング サーチ スペースに含まれているパーティションが、回線コーリング サーチ スペースよりも前に配置されます。そのため、パターン選択を連結の順序だけに頼らず、ブロックされるパターンの精度が許可されるパターンの精度よりも、すべてのケースで確実に高くなるよう注意しなければ、回線/デバイス アプローチを Cisco IP SoftPhone などの CTI デバイスに適用できません。

回線/デバイス アプローチにおけるエクステンション モビリティの考慮事項

エクステンション モビリティ機能を使用する場合、電話機のダイヤル制限は、回線/デバイス アプローチを使用することによって、その電話機へのログイン（またはログアウト）中の機能の 1 つとして自然な方法で実装できます。ログアウトされた電話機は、他の電話機やサービス（たとえば、米国では 911）のコールを制限する必要があります。一般に、公衆網を通じた市内または市外通話へのアクセスは制限されます。逆に、ユーザがログインしている電話機は、そのユーザのダイヤリング権限に応じてコールを許可し、それらのコールを適切なゲートウェイ（たとえば、同じ場所に配置されているローカル コール用の支店ゲートウェイ）にルーティングする必要があります。

サービス クラスの構築に回線/デバイス アプローチを使用する場合は、前の項で説明したものと同じ規則を、エクステンション モビリティのデバイス プロファイル コンストラクトに適用するだけで済みます。エクステンション モビリティ使用時にコール制限を適用するには、次のガイドラインを考慮してください。

• 一致する可能性のあるすべての公衆網ルート パターンが入っていて、それらのパターンを適切にルーティングする（たとえば、緊急コールと市内電話にはローカル ゲートウェイを使用し、長距離電話には中央ゲートウェイを使用する）サイト固有のパーティションを指すように、各サイトのすべての IP Phone のデバイス コーリング サーチ スペースを設定します。

• ユーザがログインしていないときでも許可されるコール（たとえば、内部内線番号と緊急サービス）以外のコールをすべてブロックするブロック トランスレーション/ルート パターンを備えたグローバル コーリング サーチ スペースを指すように、すべての IP Phone の回線コーリング サーチ デバイス（または、デフォルト ログアウト デバイス プロファイルの回線コーリング サーチ スペース）を設定します。

• エクステンション モビリティ ユーザごとに、特定のサービス クラスに対して許可しない公衆網コールを選択してブロックする（たとえば、国際コールのみをブロックする）ブロック トランスレーション/ルート パターンを備えたグローバル コーリング サーチ スペースを指すように、回線コーリング サーチ スペースをデバイス プロファイル内に設定します。一部のユーザに無制限のコール特権を与える必要がある場合は、それらのユーザを空のパーティションを備えた回線コーリング サーチ スペースに割り当てます。

エクステンション モビリティに回線/デバイス アプローチを使用することの主な利点は、図10-37 に示すように、集中型コール処理を使用するマルチサイト配置において、ユーザがホーム サイト以外の支店サイトにある IP Phone にログインしている場合でも、適切なコール ルーティングが保証されることです。

図10-37 回線/デバイス アプローチを使用したエクステンション モビリティ

この章ですでに説明したように、デバイス プロファイル内に設定した回線コーリング サーチ スペースは、ユーザがエクステンション モビリティを通じてログインすると、物理 IP Phone 上に設定されている回線コーリング サーチ スペースを置き換えます。コール ルーティングはデバイス コーリング サーチ スペースによって正しく処理されるため、ログイン操作は、単に電話のロックを解除するために使用されます。ログイン操作によって、（ブロック パターンを含んでいる）電話の回線コーリング サーチ スペースが削除され、（この単純化した例では、ブロック パターンを保持していない）デバイス プロファイルの回線コーリング サーチ スペースに置き換えられます。

コール ルーティングがすべてデバイス コーリング サーチ スペースの内部で実行されるのに対して、回線コーリング サーチ スペースは、単にブロック パターンを導入するだけです。このため、ユーザは、ホーム サイト以外のサイトにログインした場合、そのサイトのローカル ダイヤリング手順を自動的に継承します。たとえば、電話の DN は 8 桁番号として定義されているものの、各サイトの内部では、ローカル トランスレーション パターンによって 4 桁ダイヤリングが提供されているとします。この場合、別のサイトにローミングしたユーザは、ホーム サイトにいる同僚に 4 桁のみダイヤルして到達することはできなくなります。4 桁の番号は、ユーザがログインしたホスト サイトの規則に従って変換されるためです。

つまり、回線/デバイス アプローチをエクステンション モビリティに使用する場合は、エンドユーザがログイン先サイトのダイヤリング手順に従う必要があります。

自動転送の考慮事項

エクステンション モビリティを使用する集中型コール処理環境に対して回線/デバイス コーリング サーチ スペース アプローチを適用する場合、ユーザがすべてのコールを外部公衆網番号に転送できるようにする必要があるときは、自動転送の動作に注意する必要があります。

図10-38 では、エクステンション モビリティ ユーザが通常はサイト 1 を拠点としていて、そのデバイス プロファイルでは、無制限に公衆網コールを発信し、すべての着信コールを任意の公衆網番号に転送することが許可されています。

図10-38 回線/デバイス アプローチを使用したエクステンション モビリティにおける自動転送の考慮事項

「自動転送コーリング サーチ スペース」の項で説明したように、Forward All コーリング サーチ スペースは、回線およびデバイスのコーリング サーチ スペースとは連結されないため、Site1_all に設定する必要があります。Site1_all は、サイト 1 のゲートウェイを使用するすべての公衆網ルートを含んでいます。

このユーザがサイト 2 に移動して電話機 D にログインすると、ユーザのデバイス プロファイルに従って、このプロファイルの回線コーリング サーチ スペースと Forward All コーリング サーチ スペースが物理デバイスに適用されます。直接公衆網コールの場合、使用されるコーリング サーチ スペースは、回線とデバイスのコーリング サーチ スペースを連結したものです。電話 D のデバイス コーリング サーチ スペース（Site2_all）は、サイト 2 のゲートウェイを正しく指しています。

このユーザが、すべてのコールを公衆網番号に転送するように電話を設定すると、転送されるすべてのコールは、Site1_all コーリング サーチ スペースを使用します。Site1_all は、サイト 1 のゲートウェイを指したままです。この状態になると、次のような動作が発生します。

• 着信公衆網コールは、サイト 1 のゲートウェイで IP ネットワークに入り、同じゲートウェイ内で公衆網にヘアピンされます。

• サイト 1 の電話（電話 A など）から発信されるコールは、サイト 1 のゲートウェイを通じて公衆網に正しく転送されます。

• サイト 2 の電話（電話 C など）から発信されるコールは、WAN を経由してサイト 1 に到達し、サイト 1 のゲートウェイを通じて公衆網にアクセスします。同じ Cisco Unified CallManager クラスタ内の他のサイトから発信されるコールに対しても、同じ動作が適用されます。

ネットワークを設計し、ユーザをトレーニングするときは、この動作に注意してください。

（注） Cisco Unified CallManager 5.0 では、User Device Profile の回線設定ページに Secondary Calling Search Space for Forward All が新たに導入されました。このコーリング サーチ スペースは、User Device Profile の回線コーリング サーチ スペースと連結されます。これらのコーリング サーチ スペースはどちらも、最終的にデバイス プロファイルが使用される電話機のコーリング サーチ スペースから独立しています。したがって、Forward All 動作は、プロファイルが使用されるデバイスのサイト固有のコーリング サーチ スペースが提供するコール ルーティングに基づいたものにはなりません。連結の順序は、Forward All コーリング サーチ スペースが先で、その後に Secondary Calling Search Space for Forward All が続きます。

H.323 を使用している Cisco IOS でのサービス クラスの構築

次のシナリオでは、H.323 プロトコルを実行している Cisco IOS ルータにサービス クラスを定義する必要があります。

• 集中型コール処理を使用する Cisco Unified CallManager マルチサイト配置

• Cisco Unified CallManager Express 配置

集中型コール処理を使用する Cisco Unified CallManager マルチサイト配置では、通常、サービス クラスは Cisco Unified CallManager でパーティションとコーリング サーチ スペースを使用して実装します。ただし、支店サイトと中央サイト間の IP WAN 接続が失われた場合は、Cisco SRST が支店 IP Phone の制御を取得し、パーティションとコーリング サーチ スペースに関する設定は、IP WAN 接続が復旧するまですべて使用できなくなります。したがって、SRST モードで動作している支店ルータ内にサービス クラスを実装することが望ましくなります。

同様に、Cisco Unified CallManager Express 配置の場合も、ルータには IP Phone 用のサービス クラスを実装するメカニズムが必要です。

どちらの事例でも、制限クラス（COR）機能を使用して、サービス クラスを Cisco IOS ルータ内に定義します（COR の詳細については、「H.323 ダイヤル ピアを使用する Cisco IOS のコール特権」を参照）。

次の主要ガイドラインに従うと、COR 機能を調整して、Cisco Unified CallManager のパーティションとコーリング サーチ スペースという概念を再現することができます。

• 区別する必要のあるコールのタイプごとに、タグを定義する。

• 各コール タイプをルーティングするそれぞれの POTS ダイヤル ピアに対して、メンバー タグを 1 つだけ含んだ、「基本的な」発信 COR リスト（パーティションに相当）を割り当てる。

• 各種のサービス クラスに属している IP Phone に対して、メンバー タグのサブセットを含んだ、「複雑な」着信 COR リスト（コーリング サーチ スペースに相当）を割り当てる。

図10-39 では、SRST に基づいた実装例を示しています。DN が 2002 の IP Phone は、無制限の公衆網アクセスを許可され、DN が 2001 の IP Phone は、ローカル公衆網アクセスのみを許可されています。その他のすべての IP Phone は、内部番号と緊急サービスにのみアクセスできるように設定されています。

図10-39 COR を使用した Cisco SRST 用サービス クラスの構築

次の手順では、図10-39 のような Cisco IOS ソリューションの実装例とガイドラインを示します。

ステップ 1 dial-peer cor custom コマンドを使用して、各種コールの内容をわかりやすく表しているタグを定義します（この例では、Emergency、VMail、Local、LD、Intl）。

ステップ 2 dial-peer cor list コマンドを使用して、パーティションとして使用される基本的な COR リストを定義します。各リストには、タグを 1 つのみメンバーとして含めます。

ステップ 3 dial-peer cor list コマンドを使用して、コーリング サーチ スペースとして使用される比較的複雑な COR リストを定義します。各リストには、必要となるサービス クラスに従って、タグのサブセットをメンバーとして含めます。

ステップ 4 corlist outgoing corlist-name コマンドを使用して、基本的な「パーティション」COR リストを、対応する POTS ダイヤル ピアに割り当てる発信 COR リストとして設定します。

ステップ 5 cor incoming コマンドを call-manager-fallback 設定モードで使用して、「コーリング サーチ スペース」として機能する複雑な COR リストを、各種の電話 DN に割り当てる着信 COR リストとして設定します。

SRST 用の COR を配置する場合は、次の制限事項に注意してください。

• Cisco IOS Release 12.2(8)T 以降で使用可能な SRST バージョン 2.0 では、 call-manager-fallback で許容される cor incoming ステートメントの数は、最大で 5（デフォルト ステートメント含まず）です。

• Cisco IOS Release 12.3(4)T 以降で使用可能な SRST バージョン 3.0 では、 call-manager-fallback で許容される cor incoming ステートメントの数は、最大で 20（デフォルト ステートメント含まず）です。

したがって、デフォルト以外の特権を持つユーザの電話 DN が連続しておらず、SRST サイトが比較的大きい場合は、SRST モードのサービス クラスの数を減らして、これらの制限値を超えずにすべての DN に対応できるようにする必要があります。

上の例は Cisco SRST に基づいていますが、Cisco Unified CallManager Express 配置にも同じ概念を適用することができます。ただし、次の考慮事項があります。

• Cisco Unified CallManager Express を使用している場合は、サービス クラスを表現している COR リスト（コーリング サーチ スペースに相当するもの）を個々の IP Phone に直接割り当てることができます。割り当てるには、 cor { incoming | outgoing } corlist-name コマンドを ephone-dn dn-tag 設定モードで使用します。

• COR リストの設定されていない IP Phone は、COR の一般規則に従って、発信 COR リストの内容に関係なくすべてのダイヤル ピアに無制限にアクセスできます。Cisco Unified CallManager Express は、すべての電話にデフォルトの制限を適用する、 cor incoming corlist-name default コマンドに相当するメカニズムを備えていません。

コール カバレッジの配置

コール カバレッジ機能は、多くの IP テレフォニー配置で重要となる機能です。顧客サービスを重視する多くの企業では、顧客のコールを適切なサービス部門に迅速にルーティングすることが必須になります。この項では、ハント パイロット、ハント リスト、および回線グループに基づいたハンティング メカニズムを使用して、Cisco Unified CallManager Release 4.1 でコールを分配する場合の設計ガイドラインを中心に説明します。ここでは、次のトピックを主に扱います。

• 「マルチサイト集中型コール処理モデルへのコール カバレッジの配置」

• 「マルチサイト分散型コール処理モデルへのコール カバレッジの配置」

（注） コール カバレッジ機能自体はコール キューを提供せず、発信側には、コールの宛先が見つかるまでリングバック トーンが送信されます。プロンプトや Music On Hold などを提供するため、シスコでは Cisco Unified Customer Voice Portal（CVP）などの多数のコンタクト センター テクノロジーを用意しています。シスコから入手可能なコンタクト センター テクノロジーの詳細については、http://www.cisco.com/go/srnd で入手可能な資料を参照してください。

マルチサイト集中型コール処理モデルへのコール カバレッジの配置

図10-40 では、マルチサイトの集中型コール処理配置における、ハント リストの設定例を示しています。この例では、最初にリモート オフィスのオペレータを通じてハント パイロット コールが分配されることを前提としています。コールは、応答されなかった場合やコール アドミッション制御によって拒否された場合、中央サイトのオペレータまたはボイスメールにルーティングされます。

図10-40 集中型コール処理配置における複数のサイト間でのコール カバレッジ

集中型の IP テレフォニー システムでは、Automated Alternate Routing（AAR）や Survivable Remote Site Telephony（SRST）などの機能を有効にすることで、高い可用性を実現できます。AAR 機能や SRST 機能を有効にした上でコール カバレッジ機能を配置する場合は、次のガイドラインを考慮してください。

• 自動代替ルーティング（AAR）

回線グループのメンバーは、複数のロケーションおよびリージョンに割り当てることができます。ロケーションを通じて実装したコール アドミッション制御は、想定どおりに動作します。ただし、ハント パイロットから分配されているコールは、WAN の帯域幅が不足していたためにいずれかの回線グループ メンバーへのコールが Cisco Unified CallManager によってブロックされた場合には、AAR を使用して再ルーティングされることはありません。代わりに、Cisco Unified CallManager はコールを使用可能な次のメンバーまたは回線グループに分配します。

（注） ハント パイロットによって分配されるコールは、Cisco Unified CallManager Release 4.1(3) の AAR を使用できます。ただし、AAR を使用するのは、回線グループ内でボイスメール ポートを使用している場合のみにすることを強くお勧めします。

• Survivable Remote Site Telephony（SRST）

–Cisco Unified CallManager がハント パイロットのコールを受信したとき、その回線グループ メンバーの一部が、SRST モードで動作しているリモート サイトにある場合、Cisco Unified CallManager はそれらのメンバーをスキップし、使用可能な次の回線グループ メンバーにコールを分配します。Cisco Unified CallManager から見ると、SRST モードで動作しているメンバーは未登録であり、ハント パイロットのコールは未登録メンバーには転送されません。

–SRST モードで動作しているルータがハント パイロットのコールを受信したときは、コール カバレッジ機能を使用できません。このコールは、使用可能な登録済み内線番号にコールを再ルーティングする設定が追加されていない場合、失敗します。 alias コマンドまたは default-destination コマンドを Cisco IOS の call-manager-fallback モードで使用すると、ハント パイロットを宛先とするコールをオペレータ内線またはボイスメールに再ルーティングすることができます。

マルチサイト分散型コール処理モデルへのコール カバレッジの配置

Cisco Unified CallManager Release 4.1 以降では、ルート グループをハント リストに追加することができなくなりました。このため、ハント リストを使用して、コールを他のクラスタまたはリモート ゲートウェイに送信することはできません。ただし、Cisco Unified CallManager Release 4.1 で導入されたハント パイロットのハント オプション設定を使用して、ゲートウェイまたはトランクを指すルート パターンに対応付けることができます。

図10-41 は、クラスタ間トランクを使用する分散型コール処理配置における、ハント リストの設定例を示しています。この例では、ハント パイロットのコールが最初にクラスタ A の内部に分配されることを前提としています。コールに対する応答がない場合は、ルート パターンに一致する Forward Hunt No Answer 設定を使用して、コールがコール分配のためにクラスタ B に再ルーティングされます。このルート パターンは、クラスタ B に向かうクラスタ間トランクを指しています。

図10-41 分散型コール処理配置におけるクラスタ間でのコール カバレッジ

ヒント 分散型コール処理配置では、Cisco VoIP ゲートウェイとゲートキーパーを使用して、着信するハント パイロット コールの負荷共有を管理できます。あるクラスタ内でコールに応答がなかった場合は、そのコールを別のクラスタにオーバーフローしてサービスを提供できます。コールは、ゲートウェイまたはトランクを通じて IVR 処理に送信することもできます。Tool Command Language（TCL）IVR アプリケーションは、Cisco IOS ゲートウェイ上に実装できます。

ガイドライン

分散型コール処理モデルにコール カバレッジ機能を配置する場合は、次のガイドラインを考慮してください。

• コールが複数のクラスタにわたって分配される場合は、発信または着信のルート グループ デバイス上で実行される番号変換を考慮に入れて、ルート パターンを適切に設定する必要があります。番号変換が実行されない場合、設定するルート パターンとハント パイロットは、すべてのクラスタ上で同一にする必要があります。同一でない場合は、コールが適切に分配されません。

• 分散型コール処理配置では、Cisco VoIP ゲートウェイを使用して、着信ハント パイロット コールの負荷共有を管理できます。あるクラスタ内で着信コールに応答がなかった場合は、そのコールを別のクラスタにオーバーフローしてサービスを提供できます。

ヒント コールは、ゲートウェイまたはトランクを通じて IVR 処理に送信することができます。Tool Command Language（TCL）IVR アプリケーションは、Cisco IOS ゲートウェイ上に実装できます。

ハント パイロットのスケーラビリティ

トップダウン、循環、および最長アイドル時間の各アルゴリズムを使用してコール カバレッジを配置する場合は、次のガイドラインを参考にすることをお勧めします。

• Cisco Unified CallManager クラスタは、最大で 15,000 のハント リスト デバイスをサポートします。

• ハント リスト デバイスは、1,500 個のハント リストそれぞれに 10 台の IP Phone を入れた組み合せにすることも、750 個のハント リストそれぞれに 20 台の IP Phone を入れた組み合せにすることもできます。ただし、ハント リストの数が多い場合は、その数に応じて、Cisco CallManager のサービス パラメータで指定するダイヤル プラン初期化タイマーの値を大きくする必要があります。ダイヤル プラン初期化タイマーは、ハント リストを 1,500 個設定する場合、600 秒に設定することをお勧めします。

（注） コール カバレッジにブロードキャスト アルゴリズムを使用する場合、ハント リスト デバイスの数は、Busy Hour Call Completion（BHCC）の数によって制限されます。

• 1 つの回線グループ内に、コールをすべての DN に同時に送信することを目的として設定するディレクトリ番号の数は、最大で 35 までにすることをお勧めします。また、ブロードキャスト回線グループの数は、BHCC によって決まります。Cisco Unified CallManager システム内に複数のブロードキャスト回線グループがある場合、回線グループ内のディレクトリ番号の数は、35 よりも少なくする必要があります。すべてのブロードキャスト回線グループの Busy Hour Call Attempt（BHCA）の数が、1 秒あたり 35 コール セットアップを超えないようにします。