ダイヤル プラン
ダイヤル プラン
発行日;2013/04/24 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 38MB) | フィードバック

目次

ダイヤル プラン

この章の新規情報

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

ダイヤル プランのハイ アベイラビリティ

ダイヤル プランのキャパシティ プランニング

プランニングの考慮事項

ダイヤルされたパターンの認識

ダイヤリング手順によるグループ分け

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

短縮ダイヤル

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

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

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

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

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

事前の計画

設計上の考慮事項

グローバル化デザイン アプローチ

ローカル ルート グループ

+ ダイヤリングのサポート

発呼側番号変換

着信側番号変換

着信側の設定(ゲートウェイ別)

論理パーティション

ローカル化されたコールの着信

グローバル化されたコールのルーティング

ローカル化されたコールの発信

新しいデザイン アプローチの利点

Call Control Discovery(呼制御ディスカバリ)

SAF CCD の設計上の考慮事項

Intercompany Media Engine のダイヤル プランに関する考慮事項

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

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

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

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

発信 PSTN コールと IP WAN コール

緊急コール

着信コール数

ボイスメール コール

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

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

発信 PSTN コールと IP WAN コール

着信コール数

ボイスメール コール

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

SIP 電話機でのダイヤルされたパターン認識の導入

UnifiedCM のサービス クラスの構築

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

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

従来のアプローチとローカル ルート グループを使用した +E.164 ダイヤル プランのための UnifiedCM のサービス クラスの構築

+E.164 以外のディレクトリ番号の使用

ディレクトリ番号と国際 PSTN ダイヤリングの重複

その他のサービス クラス

緊急コール

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

コール カバレッジの配置

マルチサイト集中型呼処理モデルへのコール カバレッジの配置

マルチサイト分散型呼処理モデルへのコール カバレッジの配置

ハント パイロットのスケーラビリティ

Directory URI ダイヤリングの配置

ダイヤル プランの要素

IP Phone でのユーザ インターフェイス

IP Phone での発信側の変換

電話機での + ダイヤリングのサポート

SCCP 電話機でのユーザ入力

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

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

SIP ダイヤル規則

UnifiedCM におけるコール ルーティング

パターンにおける + 記号のサポート

Directory URI

UnifiedCM の外部ルート

ルート パターン

ルート リスト

ルート グループ

発信側および着信側トランスフォーメーション パターン

着信側の設定(ゲートウェイ別)

ルート グループ デバイス

ローカル ルート グループ

PSTN へのローカル フェールオーバーを使用した中央ゲートウェイ

UnifiedCM での SIP 要求のルーティング

数値 URI と Directory URI

Directory URI のルーティング

数値 URI のルーティング

UnifiedCM におけるコール特権

パーティション

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

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

Automated Alternate Routing(自動代替ルーティング)

宛先 PSTN 番号の確立

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

ボイスメールの考慮事項

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

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

デバイス モビリティ

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

Cisco Unified Mobility 固有の考慮事項

即転送(iDivert)

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

ハント パイロット

ハント リスト

回線グループ

ハント グループのログアウト

回線グループ デバイス

時間帯ルーティング

論理パーティション

論理パーティションのデバイス タイプ

ジオロケーションの作成

ジオロケーションの割り当て

ジオロケーション フィルタの作成

ジオロケーション フィルタの割り当て

論理パーティション ポリシーの設定

論理パーティション ポリシーの適用

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

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

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

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

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

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

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

Service Advertisement Framework(SAF)Call Control Discovery(CCD)

SAF フォワーダ

要求サービス

Business Edition3000 のダイヤル プランに関する考慮事項

ダイヤル プラン

ダイヤル プランは、Unified Communications システムの重要な要素の 1 つであり、すべての呼処理エージェントにとって不可欠となる部分です。概説すると、ダイヤル プランは、コールをどのようにルーティングするかを呼処理エージェントに指示する役割を果たします。具体的には、ダイヤル プランは次の機能を実行します。

エンドポイントのアドレッシング

システム内部の宛先への到達は、すべてのエンドポイント(IP Phone、FAX 機、アナログ電話機など)とアプリケーション(ボイスメール システム、自動アテンダント、会議システムなど)にディレクトリ番号(DN)を割り当てることで実現しています。

パスの選択

発信側デバイスによっては、同じ宛先に到達する場合でも、複数のパスから選択できます。また、プライマリ パスが使用不可になっている場合にはセカンダリ パスを使用できます。たとえば、IP WAN に障害が発生した場合は、コールを PSTN を介して透過的に再ルーティングできます。

コール特権

特定の宛先へのアクセスを許可または拒否することによって、複数のデバイス グループにそれぞれ別のサービス クラスを割り当てることができます。たとえば、ロビーにある電話からはシステム内部および市内の PSTN にある宛先にしか到達できないようにし、その一方で、幹部社員の電話からは無制限に PSTN へアクセスできるようにします。

番号操作

特定の状況では、ダイヤルされたストリングをコールのルーティング前に操作する必要があります。たとえば、オンネットのアクセス コードを使用してダイヤルされたコールを PSTN を通じて再ルーティングするときや、短縮コード(オペレータにつなぐ場合の 0 など)を内線番号に展開するときです。また、番号操作は、ユーザのローカル ダイヤリング手順を、コールのパスを選択するために使用されるグローバル ルートに適合させるためにも使用されます。たとえば、フランスのユーザは、New York の番号にコールする場合に 0 00 1 212 555 1234 のようにダイヤルします。Chicago にいる発信者は、同じ番号にコールする場合に 9 1 212 555 1234 とダイヤルします。これら両方のローカル形式のユーザ入力は、+1 212 555 1234 というグローバル形式に変換され、コールのパスの選択に単一のルートが使用されます。

コールのカバレッジ

特殊なデバイス グループを作成し、特定のサービスの着信コールを複数のルール(トップダウン、循環ハント、最長アイドル時間、またはブロードキャスト)に従って処理できます。この章で説明するダイヤル プラン情報は、Unified Communications の任意の配置モデルに当てはまります。特に、マルチサイト システムを配置する場合、システム設計者は、サイト固有のダイヤリング手順に加えて、ユーザの特定のグループに対してゲートウェイを使用するなどの、サイト固有のコールのルーティングについて特別に注意する必要があります。

この章では、システム設計者が、連絡先からのダイヤル、コンピュータやスマート フォンからのクリックツーコール アクション、モビリティ関連機能の採用などの、コンピューティング テクノロジーとテレフォニーがより緊密に統合された新機能を利用しつつ、テレフォニー ユーザの従来のダイヤリング手順に対応するダイヤル プランを設計するために役立つ情報を示します。この章では、次の主要な領域に関する情報を示します。

「プランニングの考慮事項」

この項では、IP テレフォニー ダイヤル プランのプランニングに関係するプロセスを詳しく説明します。取り扱う範囲は、内線番号に使用される桁数から、企業内部のダイヤル プラン アーキテクチャ全般までです (前提条件:ダイヤル プラン一般について、ある程度の知識があること)。

「設計上の考慮事項」

この項では、マルチサイト IP テレフォニー ネットワーク、エンドポイントのアドレッシング方式、サービス クラスを作成するためのアプローチ、およびコール カバレッジ機能について、設計と配置のガイドラインを示します (前提条件:Cisco Unified Communications Manager および Cisco IOS の操作知識があることを推奨)。

「ダイヤル プランの要素」

この項では、Cisco Unified Communications ダイヤル プランの要素について詳しく説明します。取り扱うトピックには、コール ルーティングのロジック、コール特権、および各種シスコ製品における番号操作の方法が含まれています (前提条件:Cisco Unified Communications Manager および Cisco IOS の操作知識があることを推奨)。この項は、製品固有のマニュアルの代替となるものではなく、また Cisco Unified Communications Manager ヘルプ ファイルに記載されているすべての情報が示されているわけでもありません。この項では、ここで示されている設計関連の概念を理解するために不可欠な、いくつかの基本的な機能的要素について重点的に説明します。

詳細については、次の Web サイトから入手可能な『 Cisco Unified Communications Manager System Guide 』、『 Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2 』、およびその他の製品マニュアルを参照してください。

http://www.cisco.com

この章の新規情報

表 9-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

表 9-1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック
説明箇所
改訂日

発呼側トランスフォーメーション

「IP Phone での発信側の変換」

2012 年 10 月 31 日

URI ダイヤリングの大文字と小文字の区別

「大文字と小文字の区別」

2012 年 10 月 31 日

CLI での SAF フォワーダの設定

「SAF フォワーダ」

2012 年 9 月 28 日

ブロック パターンの小規模な変更

「グローバル化された番号とサービス クラス」

2012 年 8 月 31 日

発呼側番号のグローバル化

「電話機の発呼側番号のグローバル化」

2012 年 6 月 28 日

タイプ A 電話機における不在コールと受信コールのディレクトリ内の発呼側番号

「電話機の発呼側番号のローカル化」

2012 年 6 月 28 日

+E.164 ダイヤル プランのサービス クラス

「従来のアプローチとローカル ルート グループを使用した +E.164 ダイヤル プランのための Unified CM のサービス クラスの構築」

2012 年 6 月 28 日

URI ダイヤル

「Directory URI ダイヤリングの配置」

「Directory URI」

2012 年 6 月 28 日

SIP 要求のルーティング

「Unified CM での SIP 要求のルーティング」

2012 年 6 月 28 日

その他 Cisco Unified Communications システム Release 9.0 向けのさまざまな更新

この章の各項で説明

2012 年 6 月 28 日

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

図 9-1 に、Cisco Unified Communications Manager(Unified CM)に基づくダイヤル プランの基本的なアーキテクチャを示します。

図 9-1 ダイヤル プランの基本的なアーキテクチャ

 

番号分析機能によって、ユーザ、ゲートウェイ、またはアプリケーションに対してどのコールが許可されるかが制御されます。コール特権(サービス クラスとも呼ばれます)は、この機能に実装されます。番号分析は、次の基本的な構成要素を使用して実装されています。

パターン(ディレクトリ番号パターンやトランスレーション パターンなど)

パターンとは、電話番号の数値表現であり、これに一致するとコール ルーティングがトリガーされます。

パーティション

パーティションは、パターンを論理グループに分割するために使用されます。たとえば、パーティションを使用すると、1000 に設定された 2 つの内線番号を異なるパーティションにプロビジョニングできます。

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

コーリング サーチ スペースを使用すると、(電話機などの)デバイスがアクセス可能なパターンのグループを制御できます。たとえば、あるサイトのデバイスに対して、内線番号 1000 を含むローカル パーティションへのアクセスを許可する一方で、異なるサイトの内線番号 1000 へのアクセスを禁止できます。

コール ルーティング機能によって、コールのパス選択が制御されます。この機能において、特定のコールを伝送するための IP トランク、PSTN トランク、または従来型の PBX への接続が選択されます。また、コール ルーティング機能では、たとえば帯域幅を使用できないため、またはネットワークの特定の部分が利用できないために IP 接続を使用できない場合に、最初の選択肢としての IP 接続からバックアップ用の選択肢としての PSTN 接続にコールを自動的にフェールオーバーできます。

これら両方の機能において、Unified CM には、システム設計者用の数多くのツールが用意されています。システム設計者は、これらのツールを使用して、番号操作を有効にしたり、さまざまな状況における呼処理の制御を実行したりできます。たとえば、システム管理者は、電話機が異なるサイト間をローミングする際に許可するコールのタイプ、電話機が通話中または呼出音は鳴るが応答しない場合のコールの処理方法、あるいはすべてのコールを自動転送する場合に電話機が使用できる転送先を設定できます。

このアーキテクチャの個別機能の基本的要素は、複数のマニュアルで説明されています。製品固有のマニュアル、および Unified CM のヘルプ ファイルには、機能に関する最も基本的な事項が説明されています。この章の「ダイヤル プランの要素」の項では、機能についてさらに詳細に説明しています。このマニュアルの「設計上の考慮事項」の項では、システム設計者がダイヤル プランを設計する場合に考慮する必要があるトップダウンのアーキテクチャ情報を示します。

ダイヤル プランのハイ アベイラビリティ

Cisco Unified CM では、ダイヤル プラン機能は、Unified CM サーバのクラスタリング機能によってデフォルトで可用性が確保されています。すべてのダイヤル プラン設定は、他の Unified CM サービスが冗長化されるのと同じメカニズムで冗長化されます。具体的には、電話機、ルート リスト、およびゲートウェイの制御に Unified Communications Manager グループが使用されて、1 つの Unified CM サーバで単一の障害が発生してもダイヤル プラン機能の可用性が確保されます。

外部トランクに依存するコール パスでは、代替ルートを使用することによってより高いレベルの可用性を確保できます。たとえば、ルート リストを使用して、特定のオフクラスタの宛先への 1 次パス、2 次パス、および 3 次パスを確立できます。優先順位の高い選択肢(IP トランクなど)が使用できない場合は、コールが正常に確立されるか、または事前に設定されたすべての選択肢が試みられるまで、次に優先順位の高い選択肢が試みられます。

オンクラスタ エンドポイント間のコール(2 つの IP Phone 間のコールなど)において、ネットワーク障害のために IP パスが使用できない場合には、Call Forward Unregistered 機能が呼び出されて、PSTN などの代替ネットワークを経由してコールをルーティングできます。ネットワークの帯域幅が不足しているために IP パスが使用できない場合には、自動代替ルーティング(AAR)機能が呼び出されて、代替ネットワークを経由してコールがルーティングされます。

さらに高いレベルの可用性を確保するには、H.323 ゲートキーパーや SIP プロキシなどの外部ダイヤル プラン解決サブシステムをプロビジョニングする場合にも、適用可能な冗長性機能を設定する必要があります。

ダイヤル プランのキャパシティ プランニング

通常、ダイヤル プランの設定は、ゲートウェイ数、CTI 接続数、コール試行(BHCA)のレートなどの、キャパシティに影響がある他の Unified CM 設定と比較して、キャパシティへの影響は大きくありません。Cisco Unified Communications Sizing Tool では、システム プロビジョニングの計算において、ダイヤル プラン情報が組み込まれます。シスコの従業員および代理店は、適切なログイン認証を経て http://tools.cisco.com/cucst からこのツールを利用できます。

プランニングの考慮事項

ダイヤル プランは、テレフォニー システムの根本となる構成要素です。ユーザがどのように宛先に到達するかを規定する規則を定義しているので、まさにユーザ エクスペリエンスの中心部分になります。このような規則には、次のものがあります。

内線番号ダイヤリング:システム上の内線番号に到達するために、何桁ダイヤルする必要があるか。

内線番号アドレッシング:内線番号であることを識別するのに何桁を使用するか。

ダイヤリング権限:特定のタイプのコールを許可するかどうか。

パスの選択:たとえば、オンネット コールには IP ネットワークを使用する。または、国内 PSTN コールにはあるキャリアを使用し、国際コールには別のキャリアを使用する。

ネットワークが輻輳した場合の代替パス自動選択:たとえば、優先使用する国際キャリアがコールを処理できない場合に、国際コールに国内キャリアを使用する。

特定番号のブロック:たとえば、有料情報サービスへのコール。

着信番号の変換:たとえば、10 桁の番号としてダイヤルされたコールの最後の 5 桁のみを保持する。

発呼側番号のトランスフォーメーション:たとえば、PSTN に発信するとき、発信者の内線番号をオフィスの代表番号に置き換える。

IP テレフォニー システムに適したダイヤル プランは、従来の TDM テレフォニー システム用に設計するダイヤル プランと基本的には違いがありません。ただし、IP ベースのシステムによって、ダイヤル プランの構造にいくつかの新しい選択肢が生まれています。たとえば、個々のサイトにいるテレフォニー ユーザは、以前はそれぞれ別の独立 TDM システムによって処理されていましたが、IP ベースのテクノロジーは柔軟であるため、1 つの IP ベース システムに包含できるようになりました。このような新しい選択肢が IP ベースのシステムによってもたらされたため、ダイヤル プランの見方を再検討する必要があります。この項では、ダイヤル プランの設計にかかわる要件を正しく導き出すために、システムの設計担当者が検討する必要のあるいくつかの要素について説明します。

ダイヤルされたパターンの認識

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

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

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

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

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

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

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

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

ダイヤリング手順によるグループ分け

ほとんどのテレフォニー ユーザは、ローカル手順に従って電話番号をダイヤルするのに慣れています。これらはオフィス ロケーション内の宛先へのコール(サイト内コール)、企業内の宛先で異なるサイト間(サイト間コール)、企業外部の宛先(オフネット コール)に適用されるさまざまなダイヤリング ルールで構成されます。これらのさまざまなタイプのコールで使用される形式は、ユーザのプリファレンスおよび地域の PSTN のダイヤリング要件によって異なります。

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

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

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

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

短縮ダイヤル

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

ダイヤリングは通常、次の 4 種類に分けられます。

サイト内、オンネットの内線番号ダイヤリング

多くのシステムで、サイト内での 4 桁または 5 桁のダイヤリングに対応しています。たとえば、カリフォルニア州の San Jose にいるシスコ従業員は、5 桁の番号ストリング 64000 を使用して、シスコの受付番号にコールできます。

サイト間、オンネットの内線番号ダイヤリング

たとえば、すべてのシスコ オフィスのシスコ従業員は San Jose の受付番号に 8 526 4000 でダイヤルできます。数字の 8 は、サイト間アクセス コードです。52 は San Jose のサイト コードです。

この形式は、オンネットでコールをルーティングする、オフネット形式を使用する代替方法よりも短いです(たとえば、カナダにいるシスコ従業員が、オンネットでコールをルーティングして、9 1 408 526 4000 とダイヤルして San Jose のシスコの受付番号に到達できるようになります)。ダイヤリング形式はオフネットの宛先への到達に使用される形式によく似ていますが、システム内のオフネット形式でダイヤルされたオンネットの宛先へのコールを保持するようにシステムは設定されています。

サイト間、オフネット ダイヤリング

サイト間のコールのルーティングは PSTN に渡すことができます。たとえば、San Francisco のあるサイトからの、New York の別のサイトへのコールは、上記で説明したオンネットまたはオフネット形式のいずれかでダイヤルできますが、PSTN を介してオフネットでルーティングされます。

オフネット ダイヤリング

宛先がオフネットで、会社のダイヤル プランの外部にあるコールの場合、Unified Communications システムでは、ユーザにとってシンプルで、地域で有効なダイヤリング形式を提供する必要があります。

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

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

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

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

たとえば、4 桁の短縮ダイヤル プランにおいて、9 をオフネット アクセス コードとして使用する場合(PSTN コールを発信する場合など)、内線番号を 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 範囲を使用しないようにするという方法があります。または DID 番号がオンネットの内線番号と一致させる必要もありません。

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

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

表 9-2 一般的な 4 桁定型ダイヤル プランでの番号割り当て

範囲
用途
DID 範囲
DID 以外の範囲

0XXX

除外(0 はオフネット アクセス コードとして使用される)

1XXX

サイト A の内線番号

418 555 1XXX

該当なし

2XXX

サイト B の内線番号

919 555 2XXX

該当なし

3XXX

サイト C の内線番号

415 555 30XX

3[1-9]XX

4[0-4]XX

サイト D の内線番号

613 555 4[0-4]XX

該当なし

4[5-9]XX

サイト E の内線番号

450 555 4[5-9]XX

該当なし

5XXX

サイト A の内線番号

418 555 5XXX

該当なし

6XXX

サイト F の内線番号

514 555 6[0-8]XX

69XX

7XXX

将来的にサポート

XXX XXX 7XXX

7XXX

8XXX

将来的にサポート

XXX XXX 8XXX

8XXX

9XXX

除外(9 はオフネット アクセス コードとして使用される)

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

サイト 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 範囲がサイトごとに異なっているため(おそらく、別の PSTN サービス プロバイダーから取得したことが原因)、サイト間で範囲を分割するには、密接な連携作業が必要です。特定の範囲内で割り当てられるサイトの数が多くなるほど、範囲全体をすべて使用することは困難になり、場合によっては不可能になります。

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

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

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

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

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

サイトの内部では、オンネット内線番号へのコールに対して、短縮ダイヤル(4 桁の内線番号など)を引き続き使用できる。

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

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

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

表 9-3 サイト コードの一般的な使用方法

サイト コード
範囲
用途
DID 範囲
DID 以外の範囲

1

1XXX

サイト A の内線番号

418 555 10XX

1[1-9]XX

2

1XXX

サイト B の内線番号

919 555 1XXX

該当なし

3

1XXX

サイト C の内線番号

907 555 1XXX

該当なし

表 9-3 では、サイト 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 ネットワーク経由でルーティングできる必要がある。このタスクは、Unified CM クラスタが 1 つしかない小規模システムの場合は単純ですが、複数の Unified CM クラスタがある大規模システムでは複雑なものになります。

事前の計画

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

設計上の考慮事項

この項では、マルチサイト配置について、ダイヤル プランの設計に関する次の考慮事項について説明します。

「グローバル化デザイン アプローチ」では、Cisco Unified Communications Manager のグローバル化ダイヤル プラン機能を使用した配置に当てはまるガイドラインとベスト プラクティスを示します。

「Call Control Discovery(呼制御ディスカバリ)」では、クラスタが、Service Advertisement Framework(SAF)呼制御ディスカバリ(CCD)サービスによって、それぞれにホストされた DN 範囲をどのようにネットワークにアドバタイズできるか、およびネットワーク内の他のコール エージェントによって生成されたアドバタイズメントにどのようにサブスクライブできるかについて説明します。

「Intercompany Media Engine のダイヤル プランに関する考慮事項」では、参加する企業間でインターネットを経由してコールをルーティングできる Cisco Intercompany Media Engine(IME)について説明します。

「マルチサイト配置用の設計ガイドライン」では、すべてのマルチサイト配置モデルに当てはまるガイドラインとベスト プラクティスを示します。

「ダイヤル プラン アプローチの選択」では、固定オンネット ダイヤリングおよび可変長オンネット ダイヤリングのダイヤル プランを作成するためのさまざまなアプローチを紹介し、この 2 番めのオプションについては、パーティション アドレッシングとフラット アドレッシングを紹介します。

「SIP 電話機でのダイヤルされたパターン認識の導入」では、SIP ダイヤル規則を利用して、SIP 電話機が特定のダイヤリング パターンを認識できるようにする方法について説明します。

次の各項では、2 つのダイヤル プラン アプローチについて詳しく分析し、それぞれの設定ガイドラインを示します。

「固定オンネット ダイヤル プランの配置」

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

次の各項では、Unified CM でサービス クラスを設定する方法について、2 つの代替方法を示します。

「従来のアプローチによる Unified CM のサービス クラスの構築」

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

「H.323 を使用している Cisco IOS でのサービス クラスの構築」では、H.323 プロトコルを実行している Cisco IOS ルータにサービス クラスを実装する方法を説明します。

「コール カバレッジの配置」では、ハント リストと回線グループを使用して Unified CM にコール カバレッジ機能を実装する場合の、ガイドラインとベスト プラクティスを示します。

グローバル化デザイン アプローチ

この項では、グローバル化された番号に基づいて簡素化されたコール ルーティングを実装するために使用されるダイヤル プラン機能について説明します。主に、オフネット コールに対して発信元にかかわらず単一のルーティング構造を使用することによって、ルーティングが簡素化されます。たとえば、異なる国にいる 2 人のユーザは、それぞれのダイヤリング手順に一致するように設定されたサイト固有のルート パターンの代わりに、同じルート パターンを使用して、それぞれのローカル ゲートウェイに対してコールを伝送できます。

このようなグローバル化を実現するためのアーキテクチャ上の主要なアプローチは、次のようにまとめることができます。

コールがシステムに着信する場合、宛先番号および発信番号はローカル形式で受け付けられますが、すぐにシステムによってグローバル化されます。

グローバル形式で表現されたルート パターンを使用してコールを宛先にルーティングするために、グローバル化された着信側番号が使用されます。グローバル形式は、81001234 のようなグローバルな企業固有の内部形式や、+E.164 形式(たとえば +12125551234)などの DID 番号のグローバル化された PSTN 表現の組み合わせとなります。

宛先が特定されると、発信番号および着信番号は、コール伝送先のエンドポイント、ネットワーク、またはシステムで必要とされる形式にローカル化されます。

したがって、設計指針は次のようになります。

コールの着信では、ローカライズ化された形式で受け付け、それらをグローバル化します。グローバル化された形式に基づいてコールをルーティングし、宛先で必要とされる形式に従ってコールをローカライズします。

Cisco Unified Communications Manager(Unified CM)には、次のダイヤル プラン グローバル化機能が備えられています。

「ローカル ルート グループ」

「+ ダイヤリングのサポート」

「発呼側番号変換」

「着信側番号変換」

「着信側の設定(ゲートウェイ別)」

「論理パーティション」

また、これらの新機能により Unified CM システムで次のことができるようになりました。

発信者の物理的な場所に基づいたコールのルーティング。

国際電気通信連合(ITU)の E.164 勧告に記載されているようなグローバル形式で発呼側番号および着信側番号を表示する。

ローカル ダイヤリング手順に基づいた形式でユーザへのコールを表示する。

発呼側番号、着信側番号、それらに対応する番号タイプのローカル要件に適合する形式で外部ネットワークへのコール(たとえば PSTN)を表示する。

発信番号の数字と番号タイプに基づき、ゲートウェイからの着信コールについての発呼側番号をグローバル形式で生成する。

一部の国の法的要件に準拠するため、各エンドポイントのジオロケーションに適用されるポリシーに基づいて、エンドポイント間のコールの確立と通話切替機能の開始を制御する。

ローカル ルート グループ

ローカル ルート グループでは、ゲートウェイへのオフネット コールのパターンを作成する機能を提供します。このパターンは、発信側への近さで選択されます。たとえば、ルート オフネット、特定の国のすべてのサイトに対する国内通話に対して、1 つのパターンを定義できます。すべてのサイトの電話機をこのパターンに一致するように設定できます。このパターンはその後、発信側電話機に関連付けられたローカル ルート グループに基づいて、コールをルーティングします。これによって、サイト 1 の電話機がサイト 1 のゲートウェイを介してコールをルーティングできるようにします。一方、サイト 2 の電話機(こちらも同じパターンを使用)はサイト 2 のゲートウェイを介してコールをルーティングします。この機能は、Unified CM 7.0 よりも前のリリースと比較した場合、オフネット コールのサイト固有のルーティング設定を簡素化します。

+ ダイヤリングのサポート

電話番号には、他の国から宛先に到達するのに必要な国際ダイヤル アクセス コードを表すために、+ 記号を使用できます。たとえば、+1 408 526 4000 は、米国にあるシスコ本社の国際表記です。この番号にコールするには、フランスの企業テレフォニー ユーザは通常 0 00 1 408 526 4000 とダイヤルする必要がありますが、英国の発信者は 9 00 1 408 526 4000 とダイヤルする必要があります。いずれの場合でも、+ をそれぞれの発信者に関連のある、適切なオフネット アクセス コード(企業テレフォニー システムで定められているとおり)に、また国際アクセス コード(PSTN キャリアで定められているとおりに)に置き換える必要があります。

システムは + で定義された宛先に直接、コールをルーティングできます。たとえば、ユーザは、シスコの米国本社の WiFi 電話のスピード ダイヤル エントリを +1 408 526 4000 とプログラムし、フランス、英国、または企業内の任意の場所でローミングしているときに、直接ダイヤルできます。それぞれの場所で、システムは宛先番号を地域で定められた番号ストリングに変換して、コールが正しくルーティングされるようにします。

同様に、着信番号が +E.164 形式で表現されている場合、デュアルモード電話からダイヤルされた電話番号は、電話機が GSM モードの場合には携帯電話通信業者ネットワーク経由で、電話機が WiFi モードの場合には企業ネットワーク経由で、直接ルーティングできます。これにより、ユーザは、特定の連絡先エントリに対して宛先番号を 1 つ保存するだけで済み、電話機が現在接続されているネットワークにかかわらずその番号にダイヤルできます。

この機能によりユーザは、システムを使用して ITU E.164 勧告に記述されている形式で表現される電話番号に変換し、正しくルーティングできます。ユーザが番号を手動で編集してローカル ダイヤリング手順に適合させる必要はありません。

発呼側番号変換

Unified CM を介してルーティングされるコールに関連付けられている発呼側番号は、電話機または PSTN に表示される前に適合させることが必要な場合があります。たとえば、+1 408 526 4000 からのコールは、宛先の電話機が米国またはカナダにある場合は、発信元が 408 526 4000 と表示されるようにする必要があります。一方、同じ番号からのコールで、宛先の電話機がフランスにある場合は、発信元が 00 1 408 526 4000 と表示されるようにする必要があります。これは主に、地域の PSTN によって定められる慣習的形式で発信側番号が表示されるようにするのが目的で、慣れ親しんだ形式でコールの発信元を識別できます。

ゲートウェイに配信されるコールでは、ゲートウェイが接続している電話通信業者が定める番号に、発呼側番号を適合させる必要があります。たとえば、フランスにあるゲートウェイに提示される +1 408 526 4000 からのコールでは、発呼側番号を 1 408 526 4000 と表し、発呼側番号タイプを International に設定することが必要な場合があります。同様に、カナダにあるゲートウェイに提示される同じ番号からのコールでは、発信側番号を 408 526 4000 とし、発呼側番号タイプを National に設定することが必要な場合があります。

この機能では、発呼側番号を Unified CM システム内のコール ルーティングで使用される形式から、電話機のユーザまたはオフクラスタ ネットワークで定められる形式に適合させることができます。


) 一部のサービス プロバイダーでは、機器に技術的な制限、または企業ポリシーや政府の規制の理由から、外国の電話番号を表す発呼側番号を受け付けない場合があります。プロバイダーが発呼側番号を受け付けない場合は、発呼側番号をスクリーニングして上書きするか、コールを拒否します。一部のネットワークでは、コールに 2 つの発信者識別子(ユーザ指定とネットワーク指定)が存在する場合があります。


着信側番号変換

Unified CM を介してルーティングされるコールに関連付けられている着信番号は、PSTN に提示される前に適合させる必要がある場合があります。たとえば、カナダにあるゲートウェイを介して PSTN に出る場合、+1 408 526 4000 に対して発信されるコールでは、着信側番号を 1 408 562 4000 に変換し、番号タイプを National に設定する必要があります。同じコールがフランスのゲートウェイに対して再ルーティングされた場合、着信側番号を 00 1 408 526 4000 に変換し、番号タイプを International に設定する必要があります。

着信側番号を操作し、着信番号の番号タイプを設定することによって、この機能では着信側番号がオフクラスタ ネットワークで定められる形式に適合するようにします。

着信側の設定(ゲートウェイ別)

デジタル インターフェイス(たとえば、ISDN PRI)を介してゲートウェイに着信するコールには、発呼側番号、および発呼側番号の番号タイプを Unknown、Subscriber、National、または International のいずれかに区別する属性が関連付けられています。組み合わせると、着信コールの発信番号と、それに関連付けられた番号タイプにより、発信者の識別情報を特定できます。これは、着信コールの発呼側番号に対して適切な数字を除去したり、プレフィックスを付加したりすることにより実行されます。着信側の設定では、4 つの発信番号タイプのそれぞれで、発呼側番号に対して数字を除去したり、プレフィックスを付加したりする個別の組み合わせを適用できるようにします。

たとえば、2 つのコールがドイツのハンブルグにあるゲートウェイに入るとします。どちらのコールも発呼側番号は 691234567 です。最初のコールは、番号タイプ Subscriber に関連付けられています。これは、発信者がハンブルグにいることを意味します。このためシティ コードはハンブルグの(40)となり、国番号はドイツの(49)になります。そのため、着信コールを完全に表すと +49 40 69 1234567 となります。この番号は、番号タイプ Subscriber の着信コールの発呼側番号に対して +49 40 をプレフィックスとして付加することにより得られます。

2 つめのコールは、番号タイプ National に関連付けられています。これは、発信者がドイツにいることを意味します。そしてこの番号にはすでに適切なシティ コード(69 がフランクフルトのシティ コード)が含まれていますが、国コードはドイツ(49)になります。2 つめの着信コールを完全に表すと +49 69 1234567 となります。この番号は、番号タイプ National の 2 つめの着信コールの発呼側番号に対して +49 をプレフィックスとして付加することにより得られます。

この機能によりシステムは、着信側番号と番号タイプに基づいて着信コールの発呼側番号をグローバル化できます。Unified CM の以前のバージョンでは、これらの設定はクラスタ全体のサービス パラメータを使用することによって実行されました。Unified CM 7.0 では、この機能でゲートウェイごとの設定を取り入れたことにより、番号タイプごとのさまざまなプレフィックスを、異なるゲートウェイに入るコールに適用できるようになりました。設定は、優先順位順にゲートウェイ上、ゲートウェイのデバイス プール上、またはクラスタ全体のサービス パラメータ上で設定できます。空白のエントリはプレフィックスとして数字が付加されないことを意味します。より優先順位の低い設定から設定を継承するには、エントリを [Default] に設定する必要があります。

所定の番号タイプ内のすべてのコールに対しては、最初に受信された発呼側番号に関係なく、プレフィックスの付加および番号削除の動作が適用されます。


) SIP トランク、または SIP ゲートウェイからのコールはすべて発呼側番号タイプ Unknown に関連付けられています。


特に、SIP ゲートウェイおよび SIP トランクに実装された SIP プロトコルによって、実質的にすべての着信コールの発呼側番号の番号タイプが Unknown になります。このため、Unified CM では、異なる発呼側番号カテゴリに異なる発呼側番号変更を適用できません。

Unified CM 7.1 以降のリリースでは、着信側の設定にコーリング サーチ スペース(CSS)の使用が導入されました。これらの CSS を使用することで、発信側トランスフォーメーション パターンに基づいて発信側に変更を適用できます。これらのパターンでは、正規表現を使用して大文字と小文字を区別したサブセットが照合され、各サブセットに別個の番号操作が実施されます。この新しい機能によって、Unified CM は異なる発呼側番号カテゴリに異なる発呼側番号変更を適用できます。たとえば、PSTN への接続に使用される SIP トランクから、番号タイプが Unknown に設定されたローカル、国内、および海外からのコールが送信されることがあります。このような場合、各コールの発呼側番号を使用して、番号タイプ Unknown に関連付けられたトランクの CSS 内の発信側トランスフォーメーション パターンが照合され、Unified CM で異なる発呼側番号カテゴリに異なる発呼側番号変更が適用されます。

論理パーティション

インドなどの一部の国には、企業外部でコールを接続するときに、企業の音声インフラストラクチャにローカル PSTN だけを使用することを義務付けた電気通信規制があります。このため、音声システムを 2 つのシステムに論理的にパーティション化する必要があります。2 つのシステムとは、企業内の Closed User Group(CUG; 非公開ユーザ グループ)通信用とローカル PSTN へのアクセス用です。ロケーション A の企業ユーザからロケーション B の別の企業ユーザへのコールは、CUG システム内で確立できますが、ロケーション A の企業ユーザから PSTN の宛先へのコールは、そのロケーションにかかわらず、ロケーション A の PSTN へのローカル アクセスを経由する必要があります。

既存のダイヤル プラン ツールを使用すると、コールが CUG の外側のエンドポイント間で行われる場合にそのコールを防止できますが、コールが進行しているときにはその新しいコール レッグの確立を防止できません。たとえば、英国ロンドンの企業ユーザが企業ネットワークを介してインドのデリにある同僚にコールするとします。コールが確立されると、デリのユーザは、ロンドンからのコールを受信した回線と同じ回線からインドのカスタマーとの会議に切り替えることになります。この非公開ユーザ グループ以外の宛先への通話切替(同じ回線上)は、Unified CM 内の既存のダイヤル プラン ツール(コーリング サーチ スペースやパーティションなど)を使用するだけでは防止できません。Unified CM 7.1 以降のリリースには、論理パーティション機能が導入されています。この機能を利用することにより、発信側だけでなく、会議や転送などの通信切替機能にも適用されるポリシーを確立し、実施できます。

Unified CM で使用可能なグローバル化機能の組み合わせにより、発信元ユーザと通信事業者で定められるローカル形式のコールを受け入れることができるようになり、着信番号と発信番号のグローバル表現を使用してコールをオンネットでルーティングできるようになります。また、宛先のユーザまたはネットワークで必要なローカル形式で電話機またはゲートウェイにコールを送信できます。ダイヤル デザイン アプローチの 3 つの側面は、次のように要約できます。

「ローカル化されたコールの着信」

「グローバル化されたコールのルーティング」

「ローカル化されたコールの発信」

ローカル化されたコールの着信

Unified Communications システム(複数のサイトがさまざまなリージョンまたは国に存在する)では、ユーザのさまざまなダイヤリング手順や、ゲートウェイの接続先のサービス プロバイダーのさまざまなシグナリング要件を満たす必要があります。各地域で異なる場合があるため、システムはローカル ダイヤリング手順とシグナリング要件を、コールが正しくルーティングされる形式に「変換」できるようにする必要があります。そのため、システムは多くのローカル化された着信要件を満たすだけではなく、あらゆる宛先パターンをグローバル化した 1 つの形式も作成する必要があります。

ローカル化されたコールの電話機への着信

電話機またはビデオ端末などのエンドポイントから発信されるコールは通常、ローカル ダイヤリング手順に慣れているユーザによってダイヤルされます。米国内の企業ユーザは、カリフォルニア州 San Jose にあるシスコ本社に到達するために 9 1 408 526 4000 とダイヤルするのに慣れていますが、一方で英国のユーザは 9 00 1 408 526 4000 とダイヤルし、フランスのユーザは 0 00 1 408 526 4000 とダイヤルします。これら 3 つのダイヤル形式は、企業のオフネット アクセス コード(9 は米国、英国、0 はフランス)、国際アクセス コード(00 は英国とフランス、米国の場合、宛先は国内のため必要なし)、宛先番号の表現(国コード(1)を含む)を表します。これら 3 つのグループのユーザは、それぞれ独自のローカル ダイヤリング手順を使用して、同じグローバル化された宛先番号(+1 408 526 4000)にダイヤルします。これら 3 つの各手順で、ローカル ダイヤリング手順のグローバルな記号として + を使用できます。

企業テレフォニー システムでは、ユーザのローカル ダイヤリング手順を正しく解釈できる必要があります。上記の 3 つの手順すべてで、ユーザはローカル ダイヤリング形式を使用して共通の宛先に到達します。ユーザ入力を認識するようにシステムを設定し、コールが正しい宛先にルーティングされ、送信されるようにします。コールはさまざまな形式で発信される可能性があるため、システムはそれらのさまざまな各形式に一致するパターン認識を用意する必要があります。

Unified CM のトランスレーション パターンはローカル形式のユーザ入力を電話機からダイヤルされたものとして、Unified Communications システム内のコールのルーティングに使用するグローバル形式に変換します。これらのパターンでは、次のものを含む、ローカル化されたすべてのダイヤリング手順が認識されるようにする必要があります。

サイト内、オンネットのダイヤリング

オフネットのローカル、国内、国際ダイヤリング

緊急コール、ディレクトリおよびオペレータ サービスなどのローカル サービス

通信事業者選択コードなど

上で説明した 3 つのコール例の場合、次のトランスレーション パターンが別々のパーティションに設定され、次のコーリング サーチ スペース(CSS)に配置されます。

米国の電話:9.1!(ドットの前の番号を削除して、先頭に + を付加します)

英国の電話:900.!(ドットの前の番号を削除して、先頭に + を付加します)

フランスの電話:000.!(ドットの前の番号を削除して、先頭に + を付加します)

いずれの場合でも、地域で有効なダイヤルされたストリングは、グローバル化された形式の + 1 408 526 4000 に変換されます。

同一サイト内の 2 人のユーザ間のコール、または異なるサイト間にいるユーザ間のコールなどのオンネットの宛先の場合、トランスレーション パターンを使用して宛先番号のグローバル化されたオンネット形式を生成する必要があります。サイト コードを使用してオンネット ダイヤリングを行ったり、電話の完全修飾 PSTN アドレスをオンネット番号として使用したりしている場合に、該当します。

たとえば、San Jose サイトにいる 2 人のユーザがお互いにコールするために 5 桁の短縮ダイヤリングを使用するとします。ユーザ A は、51234 とダイヤルしてユーザ B にコールします。このサイトで固有のトランスレーション パターンが設定され、5 で始まる 5 桁の任意のストリングが認識されます。そして着信番号はグローバル化されたオンネット形式の 800151234 に変換されます。トランスレーション パターンは、「5XXXX、先頭に 8001 を付加」として設定されます。

システム内の他のサイトにある内線 51234 との混同を避けるため、トランスレーション パターンはサイト固有(San Jose サイトの電話機のみにある CSS に含まれる)である必要があります。上の例では、オンネットのグローバル形式は、サイト間アクセス コード(8)とサイト コード(001)を使用して実装されます。システムがオンネット番号として、電話機の完全修飾 PSTN アドレスを使用していた場合、トランスレーション パターンでは先頭に +140855 を付加するのではなく、グローバル化されたオンネット番号の +1 408 555 1234 を生成します。


) 設定が簡単になるため、可能な場合は、フラット アドレッシングを使用する可変長のオンネット ダイヤリング(VLOD; Variable Length On-net Dialing)を推奨します。パーティション アドレッシングを使用する VLOD がサポートされていますが、この設定は複雑です。


電話機の発呼側番号のグローバル化

電話機から発信されたコールの発呼側番号は、コールの発信元回線のディレクトリ番号として設定されている番号に設定されます。グローバル化されたダイヤル プランのデザイン アプローチの概念に従って、すべてのコールの発信者情報をグローバル化する必要があります。DN 形式がグローバル化された内部の発信者情報に選択された形式(通常は +E.164)と異なる場合は、システムに実装されているすべての発信側トランスフォーメーションでディレクトリ番号形式とグローバル化された +E.164 形式の両方を入力として受け付けるか、または電話機からのコールの発信者情報も +E.164 形式に正しく設定することによって、発信者情報を正しく処理できます。そのためには、回線上の外部電話マスクを +E.164 に設定してから、一致するトランスレーション パターンの 「発呼側の外線電話番号マスクを使用」 オプションを設定します。ルート パターンに対して 「発呼側の外線電話番号マスクを使用」 オプションを使用しても、機能しません。それは、ゲートウェイまたはゲートウェイのデバイス プールの発信側トランスフォーメーション コーリング サーチ スペースを使用するデバイス レベルの発信側トランスフォーメーションによって、ルート パターンに設定された発信側トランスフォーメーションが上書きされるためです。したがって、発信側トランスフォーメーション コーリング サーチ スペースへの入力は、未変換のディレクトリ番号になります。

Cisco Unified CM 9.0 以降では、電話機からのコールの発呼側番号のグローバル化に、電話機の新規着信コール発信側変換コーリング サーチ スペースおよび電話機のデバイス プールを使用できます。これは、電話機から +E.164 へのコールの発呼側番号のグローバル化に推奨される方法です。この方法は、トランスレーション パターンが適用されない場合に URI でダイヤルされたコール フローの発呼側番号変換とも互換性があるからです。

グローバル形式を使用した着信コールの許可

電話機でも、グローバル形式のダイヤル番号でダイヤルされたストリングを提供します。Cisco Unified Personal Communicator などのソフトウェア エンドポイントの場合、電話機のテレフォニー ユーザ インターフェイス(TUI)から直接 + ダイヤリングを実行できます。また、ユーザによるクリックツーダイヤル アクションから実行することもできます。タイプ B の IP Phone の場合、キーパッドから + をダイヤルするには、電話機のモデルに応じて、* または 0 キーを押したままにします。また、不在コールと受信コールのディレクトリには、番号に + が含まれるエントリがある場合があります。ユーザがそれらのディレクトリからダイヤルするとき、Unified CM に入るコールは、+ で始まる着信番号になります。


) タイプ A およびタイプ B 電話機の定義については、「ダイヤル プランの要素」を参照してください。


電話機のダイヤル プランによってこれらのコールが正しく処理されるようにするには、ローカル化された形式のダイヤル番号だけではなく、グローバル化された形式も許可されるようにする必要があります。図 9-2 に、どのようにこれを実現するかを示します。

図 9-2 ローカル化およびグローバル化された TUI の許可

 

図 9-2 で、米国の IP Phone ユーザは 9011496100773 をダイヤルし、ドイツの宛先に接続してからコールを解除します。着信側は米国のユーザにコール バックし、接続してから、コールを解除します。その後米国のユーザは Received コール ディレクトリに移り、最後の受信コールのエントリ(+49 6100 773)を選択し、Dial を押します。この例では、米国のユーザは別々の 2 つのコールを同じ宛先に向けて開始します。最初のコールの場合、米国のダイヤリング手順に合わせてローカライズされた宛先番号の形式が使用されます。対応するトランスレーション パターン 9011.! に対して ユーザ入力がマッチングされます。変換されると、ルート パターン \+[^1]! がコールのルーティングに使用されます。2 つめのコールの場合、宛先番号のグローバル化された形式が使用され、ルート パターン \+[^1]! が直接使用されます。

サイトごとに設定されているコーリング サーチ スペースでは通常、次のことができます。

サイトの、ローカル化されたサイト内のダイヤリング手順

サイトにいるユーザの、ローカル化されたオフネットのダイヤリング手順

緊急コールなどの適用できるローカル テレフォニー サービス、ディレクトリおよびオペレータ サービス

オンネットおよびオフネット番号のグローバル化された形式

上記リストの最初の項目を除いて、コール ルーティングを行うために使用されるローカル化されたパターンは、通常、同一のダイヤリング ドメイン内のサイト間で再利用できます (フランスのすべてのサイトは、オフネットの番号を同じようにダイヤルします。英国のすべてのサイト、米国のサイトなども同じ)。ただし、それぞれのサイトには、独自のサイト内の短縮ダイヤル トランスレーション パターンを設定する必要があります。それは、San Jose にいるユーザが、たとえば 51234 とダイヤルしたときに(New York にいるユーザが 51234 とダイヤルした場合と比べて)、混同しないようにするためです。サイト内形式の短縮番号から宛先が同じのグローバル化されたオンネット形式への変換は、サイト固有のトランスレーション パターンを使用して行われる必要があります。このパターンでは、各サイトに、サイト固有のコーリング サーチ スペースが設定されている必要があります。

ローカル化されたコールのゲートウェイへの着信

外部ネットワーク(たとえば、PSTN )による Unified Communications システムに送信される着信番号と発信番号は通常、ローカル化されます。番号の形式は、トランク グループのサービス プロバイダーの設定によって異なります。ゲートウェイが PSTN トランク グループに接続されると、システム管理者は PSTN サービス プロバイダーに問い合わせて、この特定のトランク グループで使用される、適切なシグナリング ルールを決定します。トランク グループからシステムにコールが送信されると、発信番号と着信番号についての情報の一部は明示的に、一部の情報は暗黙的に示されます。この情報を使用して、システムはコールのグローバル化された発呼側番号および着信側番号を生成する必要があります。

着信側番号のグローバル化は、次の方法のいずれかによって実行できます。

ゲートウェイ設定で、[Call Routing Information] > [Inbound Calls] の設定を行います。ここで有効桁数を元の着信番号から取得し、プレフィックスをストリング(着信番号のグローバル化に使用する)に追加します。プレフィックスの数字は、適用可能な + 記号および国コード、エリア コード、シティ コードの追加に使用されます。

ゲートウェイのコーリング サーチ スペースによって参照される、トランスレーション パターンをパーティションに配置します。トランスレーション パターンは、ゲートウェイに接続されているトランクで使用する着信側番号の形式に一致するよう設定する必要があります。また、グローバル形式に変換する必要があります。プレフィックスの数字は、適用可能な + 記号および国コード、エリア コード、シティ コードの追加に使用されます。

H.323 トランクおよびゲートウェイでは、ゲートウェイおよびゲートウェイのデバイス プールで利用できる着信コールの着信側トランスフォーメーション設定を使用します。削除番号およびプレフィックス番号の命令を定義するか、または番号タイプごとに着信側トランスフォーメーション コーリング サーチ スペースを設定できます。

発呼側番号のグローバル化は、着信側の設定を使用して行う必要があります。この設定は、直接ゲートウェイ上で、またはゲートウェイを制御するデバイス プールのいずれかで設定します。


) 管理者がプレフィックスを Default に設定した場合、呼処理で次のレベル設定(デバイス プールまたはサービス パラメータ)を使用することを示します。それ以外の場合、フィールドが空白でなければ、設定された値がプレフィックスとして使用されます。フィールドが空白の場合、プレフィックスは何も割り当てられません。


たとえば、シスコの米国本社(+1 408 526 4000)に対して、米国の番号からコールが発信されるとします。そうするとコールはカリフォルニア州 San Jose にあるゲートウェイに送信されます。ゲートウェイに送信された着信番号は 526 4000 です。この情報は、Cisco Unified Communications システムがコールの完全な宛先番号を生成するのに十分です。この特定のトランク グループのサービス プロバイダーによって送信されたコールは、ゲートウェイに接続されたトランク グループの特性に基づいて暗示される国番号とエリア コードを継承します。これは、トランク グループによって処理されたすべての宛先 DID 番号が北米番号計画の国番号(1)、エリア コード 408 を継承していることを前提とします。そのため、この番号の生成されたグローバル形式は +1 408 526 4000 です。ゲートウェイに送信された発信番号は 555 1234 で、番号タイプは Subscriber に設定されています。この番号タイプは、国コードとエリア コードが、トランク グループで設定済みの特性から継承されたものであることを示します。このようにして、システムは発信番号が +1 408 555 1234 であると認識します。

別のコールで、発信番号が 33158405858、番号タイプが International の場合、これは発信番号のグローバル形式が +33158405858 と表現されるということを示します。

グローバル化されたコールのルーティング

すべてのケースに共通のグローバル形式で表現される宛先の場合、すべてのローカル形式を生成できる宛先番号のグローバル形式を採用する必要があります。+ 記号は ITU の E.123 勧告で使用されるメカニズムで、すべてのグローバルな E.164 PSTN 番号をグローバル一意形式で表現できます。この形式は、完全修飾 PSTN 番号と呼ばれることもあります。

システムはルーティング パターン(+ 記号を含むグローバル化された着信番号とマッチングする)を使用して設定できます。このような同一のルーティング パターンは、標準ローカル ルート グループを示すルーティング リストとルーティング グループを指します。このため、コール時に発信エンドポイントのデバイス プールから出口ゲートウェイを特定できるため、グローバルのルーティング パターンを作成できます。宛先が選択されると、地域設定と要件にコールを適合させるのに必要なすべてのタスク(発呼側番号と着信側番号)が実行されます。

ローカル化されたコールの発信

着信番号および発信番号のグローバル形式を使用して、コールが宛先にルーティングされる場合、コールが宛先に送信されるときに次のローカル化の操作について考慮する必要がある場合があります。

電話機の発呼側番号のローカル化

コールが電話機に送信されると、発信番号はグローバル形式に変換されます。これは着信側からは理解できません。ユーザは通常、国内の発信者からのコールでは、発信者の番号が短縮形式で表示されることを望みます。

たとえば、米国にいるユーザは、米国の発信者からの着信コールが、10 桁の国番号で表示され、+ 記号または国コード(1)がないものを好みます。グローバル電話番号が +1 408 555 1234 のユーザは、+1 408 526 4000 とコールすると、着信番号は、電話が鳴っている間、発呼側番号として 408 555 1234 と表示されます。これを実現するために、システム管理者は発信側トランスフォーメーション パターンを \+1.!(pre-dot; ドットの前の番号を削除)と設定する必要があります。発信側トランスフォーメーション パターンは、宛先電話機の発信側トランスフォーメーション パターン CSS(デバイス プール レベルで設定)に含まれるパーティションに配置されます。+1 408 555 1234 からのコールが電話機に送信されると、設定済みの発信側トランスフォーメーション パターンとマッチングされます。これにより +1 が削除され、電話が鳴っているときに発呼側番号が 408 555 1234 と表示されます。


) タイプ B の電話機の不在コールと受信コールのディレクトリに格納されている発呼側番号は、グローバル化された形式のままのため、ディレクトリに格納された番号ストリングを手動で編集せずに、ワンタッチでダイヤルできます。タイプ A の電話機の不在コールと受信コールのディレクトリに格納されている発呼側番号は、変換された発呼側番号です。タイプ A の電話機では、ユーザが不在コールまたは受信コールのディレクトリからコールバックできるように、変換された発呼側番号をサポートされているダイヤリング手順の形式にする必要があります。この動作により、ネットワーク内の古いタイプ A の電話機でも、グローバル化されたダイヤル プランを実装できます。



) 多くの電話機ユーザは PSTN 番号のグローバル化形式に慣れつつあります。それは主に、国境を越える携帯電話が一般に使われているためです。システム管理者は、着信番号をグローバル形式で表示させたい場合は、電話機の発信側トランスフォーメーション パターンの設定を行うことができます。


ゲートウェイの発呼側番号のローカル化

コールがゲートウェイに送信されると、発呼側番号は、トランク グループを提供する PSTN サービス プロバイダーの要件に合わせる必要があります(このトランク グループにはゲートウェイが接続されています)。発呼側番号トランスフォーメーション パターンは、発信側番号の番号ストリングと番号タイプの変更に使用できます。通常、ゲートウェイの国コードを示す発呼側番号では、+ 記号を削除し、国コードを明示するように変更する必要があります。また、それらを国のプレフィックスに置き換える必要があります。また、発呼側番号の番号タイプを National に変更する必要があります。ゲートウェイが特定のエリア、シティ コードを示すトランク グループに接続されている場合、+ 記号、国コード、ローカル エリア コードの特定の組み合わせは通常、適切なローカル プレフィックスに置き換える必要があります。また、番号タイプは Subscriber にする必要があります。

たとえば、San Francisco のユーザからのコール(+1 415 555 1234)が、最初の選択肢として San Francisco のゲートウェイ、別の選択肢として Chicago のゲートウェイを指定したルーティング リストを介してルーティングされるとします。San Francisco のゲートウェイは 2 つの発信側トランスフォーメーション パターンを使用して設定されます。

\+1415.XXXXXXX(ドットの前の番号を削除)、番号タイプ:subscriber

\+1.!,(ドットの前の番号を削除)、番号タイプ:national

コールが San Francisco のゲートウェイに送信されると、発呼側番号は両方の発信側トランスフォーメーション パターンとマッチングされます。ただし、最初のパターンの方がより正確に一致しているため、発呼側番号の処理にはこちらが選択されます。このようにして、変換された番号は 5551234、発信側タイプは Subscriber に設定されます。

ゲートウェイがコールを処理できなかった場合(たとえば、すべてのポートがビジーだった、など)、コールは PSTN に発信するために Chicago のゲートウェイに送信されます。Chicago ゲートウェイは次の 2 つの発信側トランスフォーメーション パターンを使用して設定されます。

\+1708.XXXXXXX(ドットの前の番号を削除)、番号タイプ:subscriber

\+1.!,(ドットの前の番号を削除)、番号タイプ:national

コールが Chicago のゲートウェイに送信されると、発呼側番号は 2 番めの発信側トランスフォーメーション パターンのみとマッチングされます。そのため、ゲートウェイに送信される発呼側番号は 4155551234 となり、発呼側番号タイプは National に設定されます。

ゲートウェイの着信側番号のローカル化

コールがゲートウェイに送信されると、着信側番号は、ゲートウェイが接続されているトランク グループを提供する PSTN サービス プロバイダーの要件に合せる必要があります。着信側番号トランスフォーメーション パターンは、着信側番号と着信側番号タイプの変更に使用できます。通常、ゲートウェイの国コードを示す着信側番号では、+ 記号を削除し、国コードを明示するように変更する必要があります。また、それらを国のプレフィックスに置き換える必要があります。また、着信側番号の番号タイプを National に変更する必要があります。ゲートウェイが特定のエリア、シティ コードを示すトランク グループに接続されている場合、+ 記号、国コード、ローカル エリア コードの特定の組み合わせは通常、適切なローカル プレフィックスに置き換える必要があります。また、番号タイプは Subscriber にする必要があります。

たとえば、San Francisco のユーザへのコール(+1 415 555 2222)が、最初の選択肢として San Francisco のゲートウェイ、別の選択肢として Chicago のゲートウェイを指定したルーティング リストを介してルーティングされるとします。San Francisco のゲートウェイは 2 つの着信側トランスフォーメーション パターンを使用して設定されます。

\+1415.XXXXXXX(ドットの前の番号を削除)、番号タイプ:subscriber

\+1.!,(ドットの前の番号を削除)、番号タイプ:national

コールが San Francisco のゲートウェイに送信されると、着信側番号は両方の着信側トランスフォーメーション パターンとマッチングされます。ただし、最初のパターンの方がより正確に一致しているため、着信側番号の処理にはこちらが選択されます。このようにして、変換された番号は 5552222、着信側タイプは Subscriber となります。

ゲートウェイがコールを処理できなかった場合(たとえば、すべてのポートがビジーだった、など)、コールは PSTN に発信するために Chicago のゲートウェイに送信されます。Chicago ゲートウェイは次の 2 つの着信側トランスフォーメーション パターンを使用して設定されます。

\+1708.XXXXXXX(ドットの前の番号を削除)、番号タイプ:subscriber

\+1.!,(ドットの前の番号を削除)、番号タイプ:national

コールが Chicago のゲートウェイに送信されると、着信側番号は 2 番めの着信側トランスフォーメーション パターンのみとマッチングされます。そのため、ゲートウェイに送信される着信側番号は 4155552222 となり、着信側番号タイプは National に設定されます。


) コールがゲートウェイに発信されると、発信側および着信側トランスフォーメーション パターンが、発信および着信番号にそれぞれ適用されます。



) SIP では番号タイプが示されません。そのため、SIP ゲートウェイでは、Unified CM によって設定された着信側または発信側の番号タイプの表示を受信できません。


新しいデザイン アプローチの利点

Unified CM 7. x の新しいグローバル化機能により有効になったダイヤル プラン デザイン アプローチの利点は、次のとおりです。

コールのルーティング、特にローカルから PSTN に発信する場合の簡素化された設定。

システム機能の簡素化された設定と拡張機能。次のものがあります。

自動代替ルーティング(AAR)

Emergency Responder(ER)サイト固有のフェールオーバー

Call Forward Unregistered(CFUR)

テールエンド ホップオフ(TEHO)

Cisco Unified Personal Communicator などのソフト クライアントからの E.164 番号のクリックツーダイヤル(+ 記号を含む)

ローミング中のエクステンション モビリティ ユーザまたはローミング デバイスから発信されたスピード ダイヤルの適合コール ルーティング

電話機ディレクトリ エントリ(デュアルモードの電話機を含む)からのワンタッチ ダイヤリング

IP Phone ディレクトリの Missed Calls および Received Calls リストからのワンタッチ ダイヤリング

自動代替ルーティング(AAR)

AAR 宛先マスクがグローバル化された形式に入力されている場合、およびすべての AAR CSS がグローバル化された形式で宛先にコールをルーティングできる場合、システム管理者は AAR グループの設定を簡略化できます。それは、この機能が、特定の宛先に到達するために、発信電話機の PSTN アクセスの地域要件に基づいてどの数字をプレフィックスとして付加するかを決定する唯一の機能であるためです。

さらに、ほとんどの場合、この AAR CSS の唯一の機能では、コールを発信電話機と同じ場所にあるゲートウェイにルーティングします。そのため、標準ローカル ルート グループを含むルーティング リストを指す 1 つだけのルート パターン(\+!)を使用して設定できます。この 1 つのルーティング パターンを使用してルーティングされるコールは常に発信エンドポイントに関連付けられたローカル ルート グループを介してルーティングされるため、どのリージョン、どの国にいるとしても、すべてのサイトのすべての電話でこの 1 つの AAR CSS を使用できます。

Cisco Emergency Responder

Cisco Emergency Responder(ER)へのコールのルーティングは通常、911 CTI ルート ポイントをプライマリ ER サーバに接続し、また 912 CTI ルート ポイントをバックアップ ER サーバに接続するように設定することによって行われます。

どちらの ER サーバも利用できない場合、911 コールは、PSTN が発信側電話機と同じ場所にあるゲートウェイに発信されるように指示できます。設定は次のようにします。

Call Forward No Answer(CFNA)への 911 CTI ルート ポイントおよび 912 への Call Forward Busy(CFB)、912 CTI ルート ポイントのパーティションを含むコーリング サーチ スペースを介して。

CFNA への 912 CTI ルート ポイントおよび 911 への CFB、グローバル パーティションを含むコーリング サーチ スペースを介して。グローバル パーティションは標準ローカル ルート グループを含むルート リストを指すルート パターン 911 を含む。

どちらの CTI ルート ポイントも登録解除された場合、911 へのコールは、発信電話機のデバイス プールで決定されたとおりにローカル ルート グループに転送されます。デバイス モビリティが設定されている場合、ローミング電話機は訪問したサイトのデバイス プールと関連付けられます。このため訪問したサイトのローカル ルート グループと関連付けられます。

Call Forward Unregistered(CFUR)

Call Forward Unregistered 機能によって処理されるコールが、発信側電話機と同じ場所にあるゲートウェイを使用するようにするには、電話機の CFUR 宛先を、PSTN 番号のグローバル化された+ 形式を使用して設定します。CFUR CSS は、標準ローカル ルート グループを含むルート リストを指す 1 つのルート パターン(\+!)のみを使用して設定できます。この 1 つのルーティング パターンを使用してルーティングされるコールは常に発信エンドポイントに関連付けられたローカル ルート グループを介してルーティングされるため、どのリージョン、どの国にいるとしても、すべてのサイトのすべての電話で同じ CSS を使用できます。

テールエンド ホップオフ(TEHO)

PSTN 接続料金を低くするため、システム管理者は、IP ネットワークを使用してオフネットの宛先にコールをルーティングし、PSTN への出口点を着信番号のできるだけ近くにします。同時に、コールの優先 TEHO ルートが使用できない場合、発信電話のローカル ゲートウェイを使用してコールを PSTN に送信する必要がある場合もあります。これは、特定の番号タイプの TEHO ルーティングに参加しているすべての電話で、特定の宛先番号に一致するルート パターンと一致するように設定し、その番号が最初のエントリとして、選択した TEHO 出口ゲートウェイを含むルート リストを、2 番めのエントリとして標準ローカル ルート グループを指すように設定することによって実現できます。

Call Control Discovery(呼制御ディスカバリ)

複数のコール クラスタが配置されている環境におけるダイヤル プランは、可能な場合には IP ネットワーク経由でクラスタ間でコールをルーティングし、必要な場合にはバックアップ ルートとしての PSTN を使用するように設計する必要があります。

クラスタを設定してクラスタ間コール ルーティングを可能にするには、リモート クラスタでホストされている DN 範囲を記述したパターンのセットを追加する必要があります。各リモート DN 範囲に対して、ローカル クラスタにおいて次の内容を設定する必要があります。

リモート クラスタにホストされていると認識させる番号範囲パターン

それぞれのリモート クラスタの宛先番号範囲に到達するためのプライマリ ルート、および関連するトランクとプロトコル

宛先番号範囲へのセカンダリ ルート、および宛先番号を PSTN キャリアで受け入れられる形式に変換するための関連する番号操作

この設定は、ルート パターンなどの静的なダイヤル プラン エントリを使用して、手動で行うことができます。手動で設定する場合、ルーティングするリモート範囲の量が増えるに従って、設定作業量も増えます。すべてのクラスタがゲートキーパー、SIP プロキシ、Cisco Unified CM Session Management Edition などの集中型ダイヤル プラン解決プラットフォームをポイントしている場合、作業量の増加は線形的です。ただし、この場合は、中心となるコントロール ポイントに依存することになります。

これ以外に、フル メッシュを作成する方法もあります。この方法では、各クラスタ ペアにクラスタ間トランクを設定し、他方のクラスタのリモート DN 範囲を定義するルート パターンからこれらのクラスタを参照します。このモードでは、クラスタ間のダイヤル プラン解決を制御する中心的なポイントは存在しませんが、トランクおよび関連する DN 範囲のフル メッシュではすべてのクラスタ ペアをリンクする必要があるため、クラスタの数が増えるに従って設定作業量は指数関数的に増加します。

Cisco Unified Communications Manager では、ネットワークベースの Service Advertisement Framework(SAF)Call Control Discovery(CCD; 呼制御ディスカバリ)サービスにサブスクライブすることによって、クラスタがホストする DN 範囲を自動的に交換できる機能が用意されています。SAF CCD によって、クラスタは、それぞれにホストされた DN 範囲をネットワークにアドバタイズし、ネットワーク内の他のコール エージェントによって生成されたアドバタイズメントにサブスクライブできます。SAF CCD を使用することの主な利点は次のとおりです。

同じ SAF CCD ネットワークに参加するコール エージェント間でコール ルーティング情報を自動的に配布でき、したがって新しいコール エージェントが追加されたり、コール エージェントに新しい DN 範囲が追加されたりした場合に設定作業が徐々に増大することがなくなります。

集中型ダイヤル プラン解決コントロール ポイントに依存しなくなります。

複数の Unified CM クラスタが組み合わせられた場合を含め、ルーティングが変更された場合に、コール エージェント間のコール ルーティング情報が自動的に回復されます。

「ダイヤル プランの要素」の項では、SAF CCD の基本的かつシステム的な機能の側面について説明しています。この内容は、次の URL にある最新バージョンの『 Cisco Unified Communications Manager Administration Guide 』に記載されている製品情報を補足するものです。

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

Service Advertisement Framework および呼制御ディスカバリの詳細については、「Service Advertisement Framework の呼制御ディスカバリを使用したコール ルーティングおよびダイヤル プラン配信」を参照してください。

本章のこの項は、SAF CCD サービスに参加するための Unified CM の製品設定を網羅的に説明することを目的としていません。SAF CCD サービスを提供するネットワーク内のコール エージェントとして Unified CM を使用する場合の、システム上の基本的な注意事項について説明します。次の項では、SAF CCD サービスのダイヤル プランに関する設計上の考慮事項について説明します。

SAF CCD の設計上の考慮事項

SAF CCD では、Cisco IOS ゲートウェイ、Unified CME、Unified CM などのコール エージェント間でディレクトリ番号(DN)情報を交換できます。最適なパフォーマンスを実現するには、次の基準に注意してシステムを設計する必要があります。

「グローバル化された番号のアドバタイズ」

「SAF CCD 要求サービスを通したリモート DN 範囲の取得」

「SAF CCD から取得された DN 範囲へのコールの発信」

グローバル化された番号のアドバタイズ

SAF CCD サービスに参加するコール エージェント間で交換される DN 範囲は、サイト固有のダイヤリング手順に関係なくすべてのコール エージェントに送信されるため、SAF CCD サービスを通して交換される DN の形式はグローバル形式である必要があります。グローバル形式とは、すべてのコール エージェントの間で一意な形式を指します。この形式は、任意のデバイスやコール エージェントで使用でき、ネットワーク内の任意の場所で使用できます。SAF CCD サービスにアドバタイズされるすべてのパターンは、企業内でグローバルに一意にすることを推奨します。

たとえば、次の番号をコールして、英国の Liverpool にいるユーザ Paul を呼び出すことができるとします。

同じく英国の Liverpool にいる同僚 John からコールする場合は 1234

オーストリアの Vienna にいる同僚 Wolfgang からコールする場合、または電話機を制御するコール エージェントに関係なく、世界中のオンネットの社内オフィス ロケーションにいる他のすべての同僚からコールする場合は 85551234

カリフォルニア州の Hawthorne にいるユーザ Brian は次の番号をコールして呼び出すことができます。

同じくカリフォルニア州の Hawthorne にいる同僚 Carl からコールする場合は 1234

アイルランドの Dublin にいる同僚 Bono からコールする場合、または電話機を制御するコール エージェントに関係なく、世界中のオンネットの社内オフィス ロケーションにいる他のすべての同僚からコールする場合は 84441234

この例では、Paul に関連付けられているローカル化された 4 桁の短縮形サイト内形式の番号は、ユーザ Brian の番号と競合するため、すべてのコール エージェントに送信するグローバルな識別情報としては使用できません。Paul のコール エージェントがネットワークに DN 1234 のアドバタイズメントを送信すると、同じ SAF CCD ネットワーク内の Brian のコール エージェントからアドバタイズされた DN と競合します。このような状態で Carl が 1234 にダイヤルすると、Paul または Brian のどちらを呼び出すかについて競合が発生します。

このような競合を回避するために、コール エージェントでは、常に、サイトやクラスタに固有のコンテキストに依存しないグローバル形式の番号をアドバタイズする必要があります。グローバル形式の番号は、ネットワーク上の任意の電話機からダイヤルでき、ネットワーク全体の中で宛先 DN を一意に識別するものである必要があります。このためには、主に次の 2 つの形式のグローバル DN を使用できます。

「サイト コード ベースのオンネット形式」

「+E.164 ベースのオンネット形式」

サイト コード ベースのオンネット形式

サイト間コールのほとんどがサイト コードに基づくオンネット方式を使用してダイヤルされるシステムでは、サイト コード形式の DN およびそれらを PSTN にフェールオーバーできるルールのセットをアドバタイズすることを推奨します。

サイト間アクセス コード、サイト コード、内線番号の順にダイヤルすることによって、システム内で各 DN にグローバルに到達できます。たとえば、サイト間アクセス コード 8、サイト コード 555(英国、Liverpool)、内線番号 1234 の順にダイヤルすると、企業ネットワーク内の任意の場所から Liverpool のユーザ Paul を呼び出すことができます。これらの構成要素を組み合わせることによって、ネットワーク内でグローバルに一意な DN 85551234 が生成されます。

フラット アドレッシングの可変長のオンネット ダイヤリング(VLOD)を使用して実装されたサイト コードが使用されているシステムでは、クラスタによってネットワーク内の他のクラスタにアドバタイズされる DN 範囲は、回線に設定された DN 形式と直接一致します。これにより、コールが他のコール エージェントから SAF CCD トランクに受信された場合でも、着信番号を回線内部で使用されている形式に適合させるためのディジット操作が不要になります。たとえば、クラスタが 855512XX をアドバタイズし、SAF CCD トランクで 85551234 へのコールを受信した場合、電話機を含む単一のパーティションで直接照合できます。

パーティション アドレッシングの可変長のオンネット ダイヤリング(VLOD)を使用して実装されたサイト コードが使用されているシステムでは、クラスタによってネットワーク内の他のクラスタにアドバタイズされる DN 範囲は、回線に設定された DN 形式と直接一致しません。このため、コールが他のコール エージェントから SAF CCD トランクに受信された場合、着信番号を、グローバル化された形式から回線内部で使用されているサイト固有の短縮形式に変換する必要があります。たとえば、クラスタが 855512XX をアドバタイズし、SAF CCD トランクで 85551234 へのコールを受信した場合、最初に、着信番号をグローバル形式から宛先電話機のサイト固有のパーティションで使用されているローカライズ形式 1234 に適合できる一連のトランスレーション パターンが含まれた単一のパーティションで照合する必要があります。

+E.164 ベースのオンネット形式

サイト間コールのほとんどが PSTN 形式の DN を使用してダイヤルされるシステムでは、関連する +E.164 形式で DN をアドバタイズすることを推奨します。+E.164 形式には、(オンネットかオフネットかにかかわらず)任意のシステムの任意のユーザが、任意のネットワークを経由して宛先 DN に到達するためのすべての情報が含まれています。SAF CCD サービスから取得される DN 範囲は +E.164 形式のままで保存し、ローカル ユーザ入力をその形式に一致するようにグローバル化することを推奨します。

たとえば、Liverpool のユーザ Paul が、英国クラスタの Liverpool パーティション内の 1234 として定義されている回線 DN を持つ電話機を使用しています。ただし、他のサイトのいずれかの同僚が Paul を呼び出す場合は、Paul の +E.164 形式 DID(+44 15 4555 1234)を地域で有効な形式にした番号をダイヤルします。たとえば、オーストリアの Wolfgang は 0 00 44 15 4555 1234 を、テネシー州 Memphis の Elvis は 9 011 44 15 4555 1234 をダイヤルします。Liverpool の他のサイトからコールする Ringo は、9 0154 555 1234 をダイヤルして Paul を呼び出します。世界のいずれかの地域に出張中のユーザ Edge は、ラップトップからのクリックツーコール アクションの形式で +44 15 4555 1234 にダイヤルして Paul を呼び出します。

Paul の +E.164 がアドバタイズされる形式が、必ずしもネットワーク上の他のクラスタのユーザによってそのまま文字どおり使用されるわけではありません。上記の例でも、Edge 以外のすべてのユーザは、Paul のローカル化された形式の番号を使用しています。ただし、いずれの場合でも、ダイヤルされたローカル形式をグローバル化することによって、Paul のクラスタからアドバタイズされるグローバル形式に変換できます。

各クラスタでは、ユーザ入力をローカル手順形式で受け付ける必要があります。たとえば、米国のユーザ Elvis が他の国のユーザを呼び出す場合の手動の社内ユーザ入力手順では、オフネット アクセス コード(9)、国際ルーティング コード(011)、宛先の E.164 番号(44 15 4555 1234)の順にダイヤルします。この場合、ユーザ入力のグローバル化においては、9011.!(ドットの前の番号を削除して、先頭に + を付加)などのパターンとの照合が必要です。この 1 つのトランスレーション パターンを、米国の任意のユーザから NANP 国コード 1 外部の任意の宛先へのすべてのコールに使用できます。

すべてのクラスタのすべてのユーザにとって、ユーザ入力手順を +E.164 形式にグローバル化するために必要な、地域で有効なグローバル化ルールの数はわずかです。グローバル化ルールでは、ローカルの PSTN コール、国内コール、および国際コールのグローバル化をカバーする必要があります。多くの国では、すべての国内コールに 1 つの形式だけが存在します。


) +E.164 形式で DN 範囲をアドバタイズする場合、DN 自体がホスト クラスタで +E.164 番号として定義されている必要はありません。


フラット アドレッシングの可変長のオンネット ダイヤリング(VLOD)を使用して実装された +E.164 形式が使用されているシステムでは、クラスタによってネットワーク内の他のクラスタにアドバタイズされる DN 範囲は、回線に設定された DN 形式と直接一致します。これにより、コールが他のコール エージェントから SAF CCD トランクに受信された場合でも、着信番号を回線内部で使用されている形式に適合させるためのディジット操作が不要になります。たとえば、クラスタが +4415455512XX をアドバタイズし、SAF CCD トランクで +441545551234 へのコールを受信した場合、電話機を含む単一のパーティションで直接照合できます。

パーティション アドレッシングの可変長のオンネット ダイヤリング(VLOD)を使用して実装された +E.164 形式が使用されているシステムでは、クラスタによってネットワーク内の他のクラスタにアドバタイズされる DN 範囲は、回線に設定された DN 形式と直接一致しません。このため、コールが他のコール エージェントから SAF CCD トランクに受信された場合、着信番号を、グローバル化された形式から回線内部で使用されているサイト固有の短縮形式に変換する必要があります。たとえば、クラスタが +4415455512XX をアドバタイズし、SAF CCD トランクで +441545551234 へのコールを受信した場合、最初に、着信番号をグローバル形式から宛先電話機のサイト固有のパーティションで使用されているローカル形式 1234 に適合できる一連のトランスレーション パターンが含まれた単一のパーティションで照合する必要があります。

両方の形式が必要な場合

一部のシステムでは、ユーザは、上記の両方のアプローチを使用して相互に呼び出しを行います。このような状況においては、ホスト クラスタは、サイト コード形式および +E.164 形式の両方の DN 範囲をアドバタイズする必要があります。これら 2 つの形式は、+ 記号を使用するかどうかによって区別できるため、電話機の特定のグループに対してアドバタイズされる 2 つの DN 範囲の間で重複は発生しません。

DID 以外の番号に関する特別な考慮事項

システムにおいて、DID 以外の番号をクラスタ間で到達可能にする必要がある場合には、SAF CCD を使用するように DID 以外の DN 範囲を設定できます。ただし、PSTN フェールオーバー機能は、DID に関連付けられた DN の場合のようには動作しません。たとえば、800033XX などの DID 以外の DN 範囲がアドバタイズされ、PSTN を経由してホスト クラスタの回線にコールをルーティングする DID 範囲が関連付けられていない場合は、次のいずれかを実行できます。

ネットワークの輻輳が発生しているため、後でコールを再試行する必要があるという内容を示す、発信側クラスタ内のアナンシエータ メッセージへのコールを行う PSTN フェールオーバー番号を設定します。

IVR や受付電話機などのデバイスへのコールを行う PSTN フェールオーバー番号を設定します。


) +E.164 形式では、+0 範囲を使用して、DID 以外の番号を指定できます。したがって、+0 範囲はオンネットで +E.164 形式のコールをルーティングする場合にだけ使用できます。PSTN では、コールは国コード 0 にルーティングされません。



ヒント DID 以外の範囲を設定する場合は、+0 の範囲を、DN がホストされている実際の国コード、エリア コード、およびシティ コードに分割してください。たとえば、イリノイ州 Chicago の DID 以外の範囲を +01708XXXXXXX で始まるように設定し、DID 以外の 1000 万件の番号を指定できるようにします。同様にして、ドイツの Frankfurt の範囲を +04969XXXXXXX で始まるように設定するなどします。

SAF CCD 発信コールの PSTN フェールオーバーの考慮事項

SAF CCD で検出された番号にコールが発信されると、コールは、Unified CM の [Call Control] > [Call Control Discovery] > [Requesting Service] での設定に従って、要求サービスに関連付けられた SAF CCD トランクのいずれかを経由してルーティングされます (図 9-3 を参照)。トランクでコールを受け付けることができない場合(たとえばコール アドミッション制御によってコールが拒否された場合や、トランクがダウンしている場合)、コールは、発信側デバイスの AAR Calling Search Space(CSS; コーリング サーチ スペース)経由で PSTN に送信されます。宛先番号は、PSTN と直接互換性がない形式である可能性があるため、最初に宛先番号を適合させる必要があります。

図 9-3 SAF CCD および PSTN フェールオーバー

 

各コール エージェントによって SAF CCD サービスに挿入される DN 範囲レコードには、オンネット形式の番号を PSTN で受け入れられる形式に適合させるために必要なルールが含まれている必要があります。ルールには、範囲の左端から削除する桁数([PSTN Failover Strip Digits])、削除後の着信番号の先頭に付加する番号([PSTN Failover Prepend Digits])、およびコールを PSTN に再ルーティングする場合に DN 範囲をそのまま使用するかどうか([Use HostedDN as PSTN Failover] チェックボックス)が含まれます。

たとえば、図 9-3 では、Unified CM クラスタで他のクラスタへのルートが検出されます。検出されたルートは、SAF_CCD_part という名前のパーティションに設定されます。Paris のユーザが 84081234 にダイヤルすると、最適ルーティング ロジックによって、SAF CCD で検出されたパターン 8408XXXX を使用してコールがルーティングされます。この IP ルートが使用できない場合、ダイヤル番号は ToDID 情報と組み合わせられます。この情報は、左端から 4 桁(この場合は 8408)を削除し、先頭に +1408555 を付加するように Unified CM に対して指示します。これにより、+14085551234 という番号が生成されます。この番号は、発信側電話機の AAR コーリング サーチ スペースを通して一致を検出するために使用されます。これにより、コールは \+! ルート パターンに一致し、French INtl RL ルート リストを経由してルーティングされます。最初に HQ_RG ルート グループ経由でのコールのルーティングが試みられ、失敗した場合は発信側電話機のローカル ルート グループ(この場合は Paris_RG)を使用してルーティングが試みられます。

これらのルールは、Unified CM の [Call Routing] > [Call Control Discovery] > [Hosted DN pattern] で、アドバタイズされる各 DN 範囲に対して設定されます。また、Unified CM の [Call Routing] > [Call Control Discovery] > [Hosted DN group] で、DN 範囲のグループに対して設定することもできます。

それぞれの範囲に対してより詳細にフェールオーバー番号を制御でき、[Hosted DN group] レベルで別途設定する必要もないため、[Hosted DN pattern] レベルで PSTN フェールオーバー番号を設定することを推奨します。

サイト コードを使用して DN 範囲をアドバタイズする場合

たとえば、Liverpool にいるユーザは、855512XX 範囲の番号をダイヤルすることによってオンネットで呼び出すことができます。この形式には、コールを PSTN 経由でこの宛先にルーティングするために必要な関連する DID 番号が定義されていません。このサイト コード形式を PSTN で必要な +E.164 形式(+44 15 4555 12XX)に変換するには、アドバタイズされた DN 範囲の左端の 1 桁を削除して、先頭に +44154 を付加する必要があります。この操作は S:PP と表されることもあります。S は、左端から削除する桁数を表し、PP は削除後の着信番号に付加する番号そのものを表します。この例では、変換操作は 1:+44154 と表されます。


) DN 範囲をアドバタイズするクラスタは、PSTN にフェールオーバーするための適切な情報を含む SAF CCD レコードを提供する必要があります。ルートが SAF CCD サービスに挿入されるときにこの情報が提供されない場合、各 CCD クライアント クラスタでは、取得したルートの PSTN フェールオーバー特性の適合用の設定を行う必要があります。これにより、追加の設定作業が発生し、変更が必要な場合には複数のクラスタを変更する必要があります。


着信番号の形式が +E.164 形式に変更されると、コールは、発信側デバイスの AAR CSS を経由してルーティングされます。この場合、+E.164 形式の番号に対して照合が行われる必要があります。ルート パターンが一致すると、コールはルート リスト、ルート グループ、そして最終的にはトランクやゲートウェイを経由してルーティングされます。トランクやゲートウェイでは、+E.164 から PSTN キャリアが必要とするローカル化された形式に番号を適合させるために着信側トランスフォーメーション パターンが使用されます。

+E.164 形式を使用して DN 範囲をアドバタイズする場合

この場合、DN 範囲は直接 +E.164 形式でアドバタイズされるため、PSTN フェールオーバー番号設定は必要ありません。[Hosted DN Range] 設定の下の [Use HostedDN as PSTN Failover] チェックボックスをオンにして、[Hosted DN group] のレベルで設定された PSTN フェールオーバー番号が優先されないようにすることを推奨します。この設定は、同じホストされた DN グループを通してサイト コード形式と +E.164 形式の両方の番号範囲をアドバタイズして、両方のダイヤリング形式をクラスタ間でサポートする必要がある場合に便利です。このような場合、ホストされた DN グループの PSTN フェールオーバー設定は、サイト コード形式の DN 範囲に対して適用され、+E.164 形式の DN 範囲では無視されます。


) SAF CCD の PSTN フェールオーバー番号設定では、+ 記号は 2 つの主要な役割を果たします。1 つめは、適合された PSTN フェールオーバー番号が、他のすべてのクラスタにおける他のすべてのサイト内有効範囲と重複しないようにする役割です。たとえば、4415 が有効なサイト内内線番号であるクラスタの番号は、+441545551234 と重複しません。2 つめは、ローカル コールが一部の国コードと重複する状況(たとえば、インドの国コード 91 がノースカロライナ州 Raleigh におけるローカルの 10 桁のダイヤリングと重複したり、モロッコの国コード 212 がニューヨーク州 New York のローカルの 10 桁のダイヤリングと重複したりする場合)において、着信側トランスフォーメーション パターンの照合で + を使用して区別する役割です。


複数のアドバタイジング サービスの設定

ホストされた DN グループは、ホストされた DN パターンの集合であり、Cisco Unified Communications Manager の管理ページでグループ化します。Unified CM Administration でホストされた DN グループを CCD アドバタイジング サービスに割り当てると、CCD アドバタイジング サービスによって、ホストされた DN グループに含まれているすべてのホストされた DN パターンがパブリッシュされます。

Unified CM では、複数のアドバタイジング サービスを設定できます。各アドバタイジング サービスで、ホストされた DN 範囲と、それらの範囲内の DN へのコールの受付を担当するノードとして自身をアドバタイズする呼処理ノードのグループとの間の一意な関係が確立されます。

アドバタイジング サービスは、ホストされた DN グループの 1 つと関連付けられます。このグループは、一連のホストされた DN 範囲に共通です。また、アドバタイジング サービスは、1 つの SIP SAF トランクまたは H.323 SAF トランクにも関連付けられます。これらの各トランクは、デバイス プールに関連付けられます。このデバイス プールは、Unified CM サーバ グループに関連付けられます。Unified CM サーバ グループの構成メンバーは、ホストされた DN グループ内の任意の DN 範囲のコールを担当するとしてアドバタイズされます。呼処理サーバが WAN 経由のクラスタとして展開されているシステムでは(WAN を介したクラスタリング)、電話機を処理するために使用される Unified CM サーバ グループを、電話機に設定された回線に対応する DN 範囲のアドバタイズにも使用することを推奨します。これにより、リモート SAF CCD クライアントからこれらの電話機へのコールが、電話機の制御サーバと同じ場所にある Unified CM サーバに送信されることが保証されます。

SAF CCD 要求サービスを通したリモート DN 範囲の取得

SAF CCD 要求サービスは、SAF CCD サービスに参加する他のコール エージェントにホストされた DN 範囲の取得に使用されます。要求サービスは SAF CCD トランクに関連付けられており、SAF CCD から取得された DN 範囲にコールが発信される場合に要求サービスと関連付けられたトランクを選択するために使用されます。

各 DN 範囲は、複数の属性に関連付けられています。

DN 範囲:8555XXXX や +1408555XXXX などです。

ToDID 情報:コール エージェントからのアドバタイズによって提供される PSTN フェールオーバー情報を表します。1:+1408 などです。

IP アドレス:アドバタイズされた DN 範囲をホストするコール エージェントのシグナリング用の宛先を表します。このフィールドには、アドバタイズを行うクラスタが SAF CCD サービスに DN 範囲を挿入するために使用するトランクのアドレスが設定されます。10.0.0.1 などです。

プロトコル:ホストされた DN 範囲を担当するコール エージェントと通信するために必要なシグナリング用プロトコルを表します。SIP や H.323 などです。


) アドバタイジング サービスが、2 つ以上のメンバーを持つ Cisco Unified Communications Manager グループに関連付けられたデバイス プールのトランクに関連付けられている場合、メンバーごとに 1 つの SAF CCD レコードがアドバタイズされます。つまり、3 つの Unified CM グループ メンバーを持つトランクを通して 1 つのホストされた DN 範囲をアドバタイズすると、3 つの SAF CCD レコードがアドバタイズされます。発信側クラスタによって、同じホストされた DN 範囲をアドバタイズするすべてのレコード間でロード バランシングが使用されます。


SAF CCD パーティション

クラスタでは、SAF CCD パーティションが 1 つ設定され、アドバタイズされた DN 範囲のソース、必要なプロトコル、アドバタイズで使用される DN 範囲形式(サイト コードまたは +E.164)にかかわらずすべての取得されたパターンの格納に使用されます (図 9-4 を参照)。


) SAF CCD パーティションは、[Call Routing] > [Class of Control] > [Partition] の検索では表示されません。


図 9-4 SAF 呼制御ディスカバリと静的ルーティングの統合

 

取得されたすべてのパターンが 1 つの Call Control Discovery パーティションに配置されるということは、取得されたパターンのサブセットにだけ電話機からアクセスすることはできないことを意味しています。電話機によって使用される CSS、またはダイヤルされたローカル形式の番号を SAF CCD サービスにアドバタイズするグローバル形式に適合させるために使用されるトランスレーション パターンの CSS に Call Control Discovery パーティションを含めることによって、すべてのパターンへのアクセスが実現されます。

たとえば、図 9-4 で、Paris のユーザが 84081234 にダイヤルするとします。静的に設定されたパターンのうち、ダイヤルされたストリングに一致するものはありません。ただし、SAF_CCD_Part パーティションには、SAF CCD 要求サービスから取得された DN 範囲が設定されています。パターン 8408XXXX はダイヤルされたストリングに直接一致するため、ユーザのコールを SAF CCD 対応 IP トランク経由で発信できます。この例で、Paris のユーザも Nice のユーザも SAF_CCD_part パーティションのすべてのパターンにアクセスできることに注意してください。

SAF CCD から取得された DN 範囲へのコールの発信

通常、SAF CCD から取得された DN 範囲に発信されるコールは、アドバタイズされたグローバル形式の番号をユーザがダイヤルした場合は範囲に直接一致する必要があります。ユーザがローカル形式の番号をダイヤルした場合は、グローバル化トランスレーション パターンを通して範囲に一致する必要があります。SAF CCD から取得されたパターンは、常に非緊急として取得されます。これにより、SAF CCD から取得されたパターンがグローバルな +E.164 パターンで、\+! PSTN ルート パターンの代替の一致がある場合は、部分的に重複することがあります。この場合、SAF CCD から直接、または適切なトランスレーションで変換されたローカル手順形式のダイヤルによって取得されたグローバルなオンネットの宛先をダイヤルすると、桁間タイムアウト(T302)が発生します。

発信者の DN がすでにグローバル形式(サイト コードまたは +E.164)である場合、発呼側番号はそのまま送信される必要があります。発呼側番号がローカル形式である場合、発呼側番号はローカル クラスタを出る前にグローバル化される必要があります。グローバル化を行う最良の方法は、コールの発信に使用される SAF CCD トランクの発信側トランスフォーメーション パターンを使用することです。

ユーザが、リモート コール エージェントからアドバタイズされた DN 範囲に対応する番号にダイヤルすると、次のイベントが発生します。

1. ダイヤルされたストリングは、発信側電話機の有効な CSS を通して処理されます。通常どおり、最適ルーティング プロセスが使用されます。つまり、SAF CCD から取得されたルート、またはクラスタ内にローカルに設定されたパターンの複数に一致する宛先にコールが発信された場合、コールでは、最も正確に一致するルートまたはパターンが選択されます。一致精度が等しい複数のルートまたはパターンが検出された場合は、有効な CSS で関連するパーティションが指定されている順序で使用されます。同じクラスタに属する複数の Unified CM ノードが同じルートをアドバタイズするような特殊なケースにおいては、SAF CCD サービスに参加するすべてのクラスタの SAF CCD パーティションにおいて、一致精度が等しい複数のパターンが検出されます。この場合、このパターンへのコールは、一致精度が等しいすべてのパターン間でロードバランスされます。

2. ダイヤルされたパターンへの直接一致が検出されるか(たとえば、ユーザが 84081234 をダイヤルし、これが電話機の CSS に含まれる SAF CCD パーティションのパターンと一致する場合)、またはローカル形式を SAF CCD パーティションにアドバタイズされたグローバル形式に適合させるために使用されるトランスレーション パターンを使用して照合が行われます(たとえば、テネシー州 Memphis のユーザが 9011441545551234 をダイヤルし、その番号が着信番号を +441545551234 に適合させるトランスレーション パターンに一致した場合に、トランスレーション パターンの CSS に位置する SAF CCD パーティションに +441545551234 に一致するものが検出された場合)。

3. コールは、ローカル クラスタでパターンの取得に使用された IP トランクを経由して、リモート クラスタでパターンのアドバタイズに使用されたトランクに発信されます。

4. 発信側クラスタを出るときの着信番号の形式は、リモート クラスタからアドバタイズされた形式です。

5. 発信側クラスタを出るとき、発信番号は、グローバル形式で提供される必要があります。ローカル クラスタの DN がグローバル形式でプロビジョニングされていない場合は、発信側トランスフォーメーション パターンを使用して、ローカル形式を、リモート クラスタに送信するグローバル形式に適合させる必要があります。このことは、特に、リモート ユーザが Missed および Received コール リストからダイヤル機能を使用する場合に重要となります。また、設定を簡易化するために、発呼側番号のグローバル化は、発信側クラスタで実行する必要があります。発信側クラスタで実行しない場合には、他のクラスタから着信するコールを認識して発呼側番号をグローバル化するために必要なルールをすべてのリモート クラスタに設定する必要があります。

6. 発信側クラスタと着信側クラスタとの間で IP ルートが使用できる場合、コールは、リモート クラスタにおいて、SAF CCD サービスに DN 範囲を挿入するために使用されるアドバタイジング サービスに関連付けられたトランクで受信されます。

7. コールを受信するリモート クラスタの SAF CCD トランクでは、トランクの着信コール CSS で一致が検索されます。

8. クラスタに設定されている DN が SAF CCD サービスにアドバタイズされるグローバル形式と同じ形式である場合は、SAF CCD トランクの着信コール CSS に DN パーティションが組み込まれて、一致が検索されます。コールが着信回線に提供されます。

9. クラスタに設定されている DN が SAF CCD サービスにアドバタイズされるグローバル形式とは異なる形式である場合は、SAF CCD トランクの着信コール CSS に、グローバル形式を回線の DN に設定されたローカル形式と照合するためのトランスレーション パターンが含まれたパーティションが組み込まれて、一致が検索されます。コールが着信回線に提供されます。

10. ステップ 6. で、2 つのクラスタ間で IP ルートが使用できない場合は、着信番号に PSTN フェールオーバー番号トランスフォーメーション ルール(ToDID ルール)が適用されて、その結果生成された宛先番号が発信側デバイスの AAR CSS での一致の検索に使用されます。

11. この時点で、着信番号は +E.164 形式になっており、ルート リスト、ルート グループ、およびゲートウェイ(またはトランク)の組み合わせを指すルート パターンとの照合に使用されます。

12. コールがゲートウェイまたはトランクから出るときには、トランスフォーメーション パターンを使用して、発呼側番号および着信側番号の両方を、PSTN キャリアが必要とする形式に適合させる必要があります。この段階で、コールは PSTN に送信されます。

13. コールがリモート クラスタに到達すると、コールは通常の着信 PSTN コールと同様に処理されます。


) VoPSTN アプローチを配置する場合などのように、設計においてすべてのコールを PSTN を経由して SAF CCD から取得されたルートにルーティングすることを意図している場合は、単純に 1 kbps の帯域幅に設定されたコール アドミッション制御の静的ロケーションに SAF 要求サービスの関連トランクを配置します。これにより、すべてのコールが、強制的に発信側デバイスの AAR CSS を経由してルーティングされます。


Intercompany Media Engine のダイヤル プランに関する考慮事項

Cisco Intercompany Media Engine(IME)を使用すると、参加企業間でインターネット経由でコールをルーティングできます。電話機が IME に参加し、[PSTN Access] としてマークされているトランクまたはゲートウェイ経由でコールを発信した場合、発信番号や着信番号を含むコールのレコードが企業の IME サーバに送信されます。このレコードは、以降にインターネット経由で行われるコール ルーティングにおいて、IME に参加している 2 つの異なる企業の番号のペアにフラグを設定するために使用されます。IME サーバは、同じ 2 つの番号間のコールを再度検出すると、Cisco Unified Communications Manager(Unified CM)に対してこのコールをインターネット経由でルーティングするように指示します。

このように番号のペアを保持する場合、参加しているすべての IME 対応の Unified CM クラスタにおける番号を一貫性を維持しつつ正規化することが課題となります。コールは、最初は PSTN 経由で発信され、これらのコールは異なる都市、地域、州、国などの境界を横断することがあるため、ユーザがダイヤルする番号の形式は大きく異なります。同様に、会社によって、DN を回線に割り当てるときのアプローチが異なることがあります。

IME サービスに参加するコールの発信番号および着信番号は、+E.164 形式を使用して識別することを推奨します。+E.164 形式では、一貫性のある結果を保証するために必要な正規化(すべての番号を + で始め、その次に関連する DID 番号の国コードを付加するなど)およびグローバル化が可能です。

[PSTN Access] としてマークされたトランクまたはゲートウェイに対してコールを発信すると、トランクまたはゲートウェイに関連付けられた IME E.164 トランスフォーメーション プロファイルが適用されます。これにより、発呼側番号および着信側番号に一連のトランスフォーメーション パターンが適用されます。発信コールでは、IME サーバに送信されるレコードで、変換後の番号が使用されます。


) IME E.164 トランスフォーメーション プロファイルは、Unified CM の [Advanced Features] > [Intercompany Media Services] > [E.164 Transformation] で設定されます。


[Intercompany Media Services] > [E.164 Transformation] の設定によって、発信コールに対するトランスフォーメーション パターンの適用が可能になります。設定は、発信側と着信側で分かれています。それぞれに対して、発信側または着信側トランスフォーメーション パターンが含まれているパーティションを含む CSS を設定できます。トランスフォーメーションは、元の番号(ルート パターンに一致したときの形式の番号)またはルーティング用に変換された番号(ルート リスト トランスフォーメーションが適用された後の形式の番号)に対して適用されます。

発呼側番号の場合:

発信側設定を検討する場合の元の番号は、ルート パターンに一致した電話機の DN です。ルーティング用に変換された番号は、ルート リストによって発呼側番号操作が行われた後の電話機の DN です。

たとえば、85551234 と設定された DN から、PSTN 経由で 91415551000 にコールを発信します。コールは、トランスレーション パターン 91[2-9]XX[2-9]XXXXXX を使用して発信されます。トランスレーション パターンは、着信側番号を +14155551000 に、発呼側番号を +14085551234 に変更するように設定されています。次に、このコールは、発呼側番号を 408 555 1234 に、着信側番号を 415 555 1000 に変更するルート リストが設定されたルート パターン \+! に一致します。

元の番号にトランスフォーメーションを適用するように [Outgoing Calling Party Settings] が設定されている場合は、[Outgoing Party E.164 Transformation CSS] の発信側トランスフォーメーション パターンの照合に +14085551234 が使用されます。

ルーティング用に変換された番号にトランスフォーメーションを適用するように [Outgoing Calling Party Settings] が設定されている場合は、[Outgoing Party E.164 Transformation CSS] の発信側トランスフォーメーション パターンの照合に 4085551234 が使用されます。

着信側番号の場合:

着信側設定を検討する場合の元の番号は、ルート パターンに一致するダイヤルされた番号です。上記の例では、元の番号は +14155551000 です。

ルーティング用に変換された番号は、ルート リストによって番号操作が行われた後の電話機の宛先です。上記の例では、4155551000 です。

変換が番号のどの形式に適用されるかにかかわらず、変換によって、IME サービスに送信される正規化されたグローバル形式の番号が生成される必要があります。

コールが [PSTN Access] としてマークされたトランクおよびゲートウェイから受信される場合、発信番号および受信番号が受信される形式は、IME サービスに送信される前に正規化およびグローバル化される必要があります。発信番号および着信番号の着信形式を IME サービスで必要とされる +E.164 形式に適合させるために、[Incoming Transformation Profile Settings] を使用できます。ここでは、[Incoming Calling Party Transformation Profile] および [Incoming Called Party Transformation Profile] の設定が可能です。それぞれに対して、発信側または着信側トランスフォーメーション パターンが含まれているパーティションを含む CSS を設定できます。

発信番号のトランスフォーメーションは、ルーティング用に変換された番号、つまりトランクまたはゲートウェイのレベルで [Incoming Calling Party Settings] によって処理された番号に適用されます。

着信番号のトランスフォーメーションは、着信コールのゲートウェイまたはトランクの CSS に提供された番号に適用されます。

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

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

ルーティング ループを防ぐには、すべての PSTN ゲートウェイのコーリング サーチ スペースに、同じゲートウェイにコールを送信できるルート リストおよびルート グループに割り当てられている外部ルート パターンが含まれているパーティションを含めないでください。

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

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

自動代替ルーティング(AAR)を配置する場合は、IP Phone 上に設定されている外部電話番号マスクまたは AAR 宛先マスクが、各種 AAR グループによって付加されるどのプレフィックスとも競合しないようにする必要があります。たとえば、複数の国にわたる配置の場合、0 などの国内アクセス コードは、それらがグローバル E.164 アドレスの一部でない限り、マスクに含めないでください。AAR を設定する最も簡単な方法は、電話機の完全な E.164 アドレス(+ 記号を含む)として AAR 宛先マスクを設定することです。

強制的にオンネットの宛先にダイヤルできますが、PSTN コールとしてダイヤルすると、クラスタ内のオンネットにルーティングされます。このためには、各サイトの E.164 DID 範囲に一致するトランスレーション パターンを追加し、このパターンによって、宛先内線番号に一致するように番号を操作します。たとえば、1234 とダイヤルすることによって DN にオンネットで到達可能な場合で、システム内の誰かがこの同じ宛先を 9 1 415 555 1234 とダイヤルしたとき、トランスレーション パターン 9 1 415 555.1XXX(ドットの前のすべての番号を削除し、変換後の番号にオンネットでコールをルーティングします)を作成することにより、強制的にコールをオンネットのままにできます。ただし、「オンネット強制」トランスレーション パターンを含んだパーティションを除外し、PSTN を指す標準ルート パターンを含んだパーティションを含むように、AAR コーリング サーチ スペースを設定してください。IP WAN が帯域幅外になったときに自動 PSTN フェールオーバーができるようになります。

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

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

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

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

この方法では、N 個のルート パターンを N セット、サイト固有のパーティション内に設定します。各パターンが、適切なリモート サイト ルート グループを最初の選択肢として保持し、ローカル サイト ルート グループを 2 番めの選択肢として保持しているルート リストを指すようにします。たとえば図 9-5 では、ブラジル、Paris(フランス)のあるサイトへのローカル フェールオーバー TEHO ルーティングには専用のルート パターン、およびブラジルの TEHO ゲートウェイを最初の選択肢、Paris のゲートウェイを別の選択肢としてコールをルーティングするためのルート リストが必要です。パターンはサイト固有のルート リストにリンクしているため、他のサイトで再利用することはできません。同様に、Ottawa(カナダ)にあるサイトで、カナダでは、Ottawa 固有のルート リストを指す専用のルート パターンで、Ottawa にあるゲートウェイへのローカル フェールオーバーを許可する必要があります。

図 9-5 ローカル ルート グループを持たない TEHO

 

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

ローカル ルート グループを持つ TEHO のローカル フェールオーバー

ローカル ルート グループでは TEHO ルートのローカル フェールオーバーが、サイトごとのルート パターンを作成せずに実装できるようにします。 図 9-6 の例の場合、Paris と Ottawa のサイトで単一の TEHO パターンとルート リストが使用されます。これら 2 つのサイトのユーザ入力は同じではないため(フランスのユーザはブラジルの宛先をカナダのユーザとは異なる方法でダイヤルする)、設定は、ユーザ入力をグローバル化するトランスレーション パターンに依存します。最初のエントリがブラジルのルート グループ、2 番めのエントリが標準ローカル ルート グループであるルート リストを指す、単一の、クラスタ全体のルート パターンの照合に、グローバル形式が使用されます。ローカル ルート グループは、発信側デバイスが Paris のデバイス プールにある場合は Paris のルート グループに、発信側デバイスが Ottawa のデバイス プールにある場合は Ottawa のルート グループによって解決されます。

図 9-6 ローカル ルート グループを持つ TEHO

 

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

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


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


マルチクラスタ システムに関する追加の考慮事項

複数サイトの配置(複数の Unified CM クラスタを含む)のダイヤルプランを設計する場合は、前の項で説明した考慮事項に加えて、次のベスト プラクティスに従ってください。

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

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

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

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

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

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

次のガイドラインに従うと、複数の Unified CM クラスタにわたってテールエンド ホップオフ(TEHO)を実装できます。

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

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

宛先 Unified CM クラスタに含まれているクラスタ間トランク コーリング サーチ スペースに、ローカル PSTN 番号に一致するルート パターンを備えたパーティションを含めます。また、必要に応じて、適切な着信側番号トランスフォーメーション パターンを使用して番号操作を適用します(たとえば、コールを PSTN に送信する前にエリア コードを除去します)。

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

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

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

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

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

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

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

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

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

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

ほとんどのサイト間コールで使用される転送ネットワークは何か(PSTN または IP WAN)。

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

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

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

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

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

 

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

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

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

短縮内線番号を使用して、すべての電話を一意的に識別する。

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

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

図 9-8 では、単一 Unified CM クラスタ配置での実装例を示しています。

図 9-8 固定オンネット ダイヤル プランの配置の例

 

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

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

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

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

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

「発信 PSTN コールと IP WAN コール」

「着信コール数」

「ボイスメール コール」

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

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

発信 PSTN コールと IP WAN コール

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

別の Unified CM クラスタまたは Cisco Unified Communications Manager Express(Unified CME)への短縮ダイヤリングも、ゲートキーパーを介して可能になります。これらの IP WAN コールについては、ゲートキーパーに送信する前に、トランスレーション パターンを通じて短縮ストリングを完全な E.164 に展開することを推奨します。

緊急コール

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

http://www.cisco.com

着信コール数

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

ボイスメール コール

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

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

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

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

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

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

表 9-4 フラット アドレッシングを使用する可変長ダイヤル プランのコーリング サーチ スペースとパーティション

コーリング サーチ スペース
パーティション
パーティションの内容

Site1_css

Site1Translations_pt

サイト 1 の短縮ダイヤルのためのトランスレーション パターン

Site1PSTN_pt

サイト 1 の PSTN ルート パターン(サービス クラスに基づいて、他にもパーティションが必要)

Internal_pt

すべての IP Phone の DN(一意形式)

...

...

...

SiteN_css

SiteNTranslations_pt

サイト N の短縮ダイヤルのためのトランスレーション パターン

SiteNPSTN_pt

サイト N の PSTN ルート パターン(サービス クラスに基づいて、他にもパーティションが必要)

Internal_pt

すべての IP Phone の DN(一意形式)

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

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

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

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

CTI ベースのアプリケーション(Cisco Emergency Responder など)がサイト間で使用される。


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


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

サイト内の 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 が表示されます。

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

表 9-5 図 9-9 の顧客ネットワークのサイト コード

San Jose
New York
Dallas
London
Paris
Milan

サイト コード

408

212

972

442

331

392

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

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

「発信 PSTN コールと IP WAN コール」

「着信コール数」

「ボイスメール コール」

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

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

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

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

 

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

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

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

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

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


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


発信 PSTN コールと IP WAN コール

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

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

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

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

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

オプション 2:8 桁番号と E.164 アドレス(集中型 PSTN フェールオーバーを使用)

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

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

 


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


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

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

オプション 3:8 桁番号と E.164 アドレス(分散型 PSTN フェールオーバーを使用)

このオプションでは、図 9-11 に示すように、欧州の 8 桁範囲に一致し、それらを対応する E.164 番号に変換するグローバルな一連のトランスレーション パターンを使用します。トランスレーション パターンでは、グローバル コーリング サーチ スペース(北米番号計画内(NANP)のすべてのサイトで使用)を使用し、コールは NANP の PSTN パーティション内の国際 PSTN ルート パターンとマッチングします。国際 PSTN ルート パターンは、IP WAN ルート グループを最初の選択肢として保持し、標準ローカル ルート グループを別の選択肢として保持しているルート リストを指しています。ゲートキーパーは、E.164 アドレスをゾーン プレフィックスとして使用するように設定します。

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

 

IP WAN が使用不可になった場合には、このソリューションによりローカル サイトのゲートウェイを使用して自動 PSTN フェールオーバーが提供されるため、IP WAN 帯域幅の使用効率は最適なものになります。ローカル ルート グループ コンストラクトの出現により、このアプローチは実質的に 2 番めの選択肢に優先します。このコンストラクトは同じレベルの設定を必要としますが、ローカル PSTN フェールオーバーを行えるためです。

このソリューションでも、PSTN コールとしてダイヤルされた欧州サイトへのコールは、IP WAN が使用可能な場合、ローカル ゲートウェイを使用する自動 PSTN フェールオーバーによって、オプション 2 と同様に自動的にオンネットになります。これは実質的に、NANP サイトから発信されたすべてのオフネットの欧州でのコールに TEHO 機能の形式を提供します。オンネットの宛先としてダイヤルされたコールのみが IP WAN に送信される場合は、発信側でオンネットのクラスタ間宛先としてダイヤルされた場合にのみ IP WAN にコールを送信するよう、アプローチを変更できます。図 9-12 に、このアプローチを示します。

図 9-12 クラスタ間コールのみの IP WAN アクセス

 

着信コール数

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

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

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

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

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

ボイスメール コール

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

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

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

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

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

トランスレーション パターンで、ローカル形式のユーザ入力を許可し、完全な E.164 番号を取得できるようにグローバル化するよう設定します。グローバル化された番号は CSS E164Routing を介してルーティングされます。この例では、2 つのデバイスのコーリング サーチ スペースのみを必要とします。1 つは、Paris のサイトからのローカル形式のユーザ入力を受け入れますが、すべてのフランスのサイトで再利用できます。もう 1 つは Ottawa サイトからのユーザ入力を受け入れますが、すべての NANP サイトで再利用できます。

E.164 ルーティング パーティション(この例では E164_part)を設定します。PSTN コールをルーティングするルート パターンとルート リストの適切なセットを作成します。この例では、ローカル ルート グループへのグローバル化されたすべての宛先 PSTN コールをルーティング可能な単一のクラスタ規模のルート パターン \+! を使用します。加えて、既存のオンクラスタ E.164 プレフィックスを照合し、コール バックを OnCluster_phones パーティションにルーティングするトランスレーション パターンを作成します。

Paris のユーザが番号をダイヤルすると、French_loc2glob_part パーティションにあるトランスレーション パターンを使用してグローバル化され、変換された番号は E164Routing CSS を介してルーティングされます。ダイヤルした宛先がクラスタ DN ではない場合は、同時に汎用パターン \+! および緊急トランスレーション パターンと、E164_part パーティション内の特定のサイト プレフィックスとが一致します。より特殊なサイト プレフィックスが選択され、OnCluster コーリング サーチ スペースによってコールがオンクラスタ DN に拡張されます。この 2 段階のルーティングは、オンネット宛先にダイヤルする場合の T.302 桁間タイムアウトを避けるために必要です。ダイヤルした宛先がクラスタ上の電話機ではない場合は、E164Routing CSS を介してルーティングされたグローバル化された番号は E164_part パーティションの \+! パターンのみと一致し、変換されたコールは PSTN にルーティングされます。

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

 

この設定変数では、ダイヤリング ルールを簡素化して、使用しやすくします。宛先がサイト内にある場合、短縮ダイヤル(見やすくするために 図 9-13 では省略)を使用します。宛先がサイト外にある場合、オンネットかオフネットかにかかわらず、オフネット PSTN 形式でダイヤルします。

実質上オンネット PSTN コールを強制することになるため、AAR を設定して、IP WAN の帯域幅が十分にない場合でも PSTN 経由でコールを発信できるようにしてください。

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

「不在履歴」と「着信履歴」のディレクトリには、電話機にコールが提供されたときに表示されたとおりの電話番号が表示されます。DN は + を使用して E.164 番号として設定されます。ワンタッチ ダイヤリングが可能です。 図 9-13 で、電話機のデバイス CSS は、+ 記号を含むグローバル化された E.164 形式を使用して、直接 DN にコールをルーティングできます。

SIP 電話機でのダイヤルされたパターン認識の導入

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

同じサイト内でのコールのための短縮ダイヤル パターン(固定オンネット ダイヤル プランの場合、短縮ダイヤル パターンがサイト間コールに使用される場合があります)

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

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

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

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

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

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

短縮ダイヤルは 4 桁(サイト間コールに短縮ダイヤルが使用されるかどうかは無関係)

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

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

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

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

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

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

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

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

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


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


表 9-6 7940_7960_OTHER ダイヤル規則

説明
パターン
タイムアウト
効果

短縮形の 2XXX

2...

0

これら 6 個の範囲の組み合わせは、すべてのサイトで使用できる 4 桁の短縮ダイヤル パターンを表します。[2-7]XXX と一致するいずれかのストリングがダイヤルされると、そのストリングはすぐに、Unified CM に送信されます(timeout = 0)。

短縮形の 3XXX

3...

0

短縮形の 4XXX

4...

0

短縮形の 5XXX

5...

0

短縮形の 6XXX

6...

0

短縮形の 7XXX

7...

0

サイト間ダイヤリングの 8.XXXXXXX

8、.......

0

8 が認識されるとセカンド ダイヤル トーンが再生され、さらに 7 桁が収集されます。その後、すぐに Unified CM への転送が行われます(timeout = 0)。

緊急の 911

9、11

0

9 が認識されるとセカンド ダイヤル トーンが再生され、番号 11 が収集されます。その後、すぐに Unified CM への転送が行われます(timeout = 0)。

緊急の 9.911

9、911

0

9 が認識されるとセカンド ダイヤル トーンが再生され、番号 911 が収集されます。その後、すぐに Unified CM への転送が行われます(timeout = 0)。

ローカル PSTN の 7 桁

9、.......

3

9 が認識されるとセカンド ダイヤル トーンが再生され、さらに 7 桁が収集されます。ローカル PSTN の 10 桁ダイヤリングが設定されていると、ユーザは 3 秒のタイムアウトの間にダイヤリングを続行できます。

ローカル PSTN の 10 桁

9、...........

0

9 が認識されるとセカンド ダイヤル トーンが再生され、さらに 10 桁が収集されます。その後、すぐに Unified CM への転送が行われます(timeout = 0)。

長距離

9、1..........

0

9 が認識されるとセカンド ダイヤル トーンが再生され、さらに 10 桁が収集されます。その後、すぐに Unified CM への転送が行われます(timeout = 0)。

6 秒の桁間タイムアウトによる国際ダイヤル

9、011*

6

9 が認識されるとセカンド ダイヤル トーンが再生され、その後、011 と不定の桁数が収集されます。ユーザは、不完全なストリングへのコールをトリガーすることなく、6 秒のタイムアウトの間にダイヤリングを一時停止できます。

ダイヤリングの終わりとして # を使用した国際ダイヤル

9、011*#

0

9 が認識されるとすぐにセカンド ダイヤル トーンが再生され、その後、011 と不定の桁数が収集され、# によって終了します。Unified CM にすぐに転送されます(timeout = 0)。

オペレータ

0

0

0 が検出されると Unified CM にすぐに転送されます(timeout = 0)。

表 9-7 7905_7912 ダイヤル規則

説明
パターン
効果

短縮形の 2XXX

2...t0

これら 6 個の範囲の組み合わせは、すべてのサイトで使用できる 4 桁の短縮ダイヤル パターンを表します。[2-7]XXX と一致するいずれかのストリングがダイヤルされると、そのストリングはすぐに、Unified CM に送信されます(t 0)。

短縮形の 3XXX

3...t0

短縮形の 4XXX

4...t0

短縮形の 5XXX

5...t0

短縮形の 6XXX

6...t0

短縮形の 7XXX

7...t0

サイト間ダイヤリングの 8.XXXXXXX

8.......t0

番号 8 とそれに続く 7 桁が収集された後、すぐに Unified CM に転送されます(t0)。

緊急の 911

911t0

番号 911 が収集され、すぐに Unified CM に転送されます(t0)。

緊急の 9.911

9911t0

番号 9911 が収集され、すぐに Unified CM に転送されます(t0)。

ローカルの 7 桁と LD

9.......t4>#....t1

番号 9 とそれに続く 7 桁が収集され、さらに 4 秒間に最大 4 桁までダイヤルできます。さらに 4 桁を入力した場合、それらは 1 秒後に Unified CM に送信されます。# は、9 と 7 桁が入力された後の終了文字として認識されます。

国際

9011>#t6-

番号 9 011 と、それに続く不定の桁数が収集されます。ユーザは、不完全なストリングへのコールをトリガーすることなく、6 秒のタイムアウトの間にダイヤリングを一時停止できます。# を終了文字として使用できます。

オペレータ

0

0 が検出されると Unified CM にすぐに転送されます(timeout = 0)。

Unified CM のサービス クラスの構築

Unified CM では、従来のアプローチおよび回線/デバイス アプローチという、ユーザおよびデバイスにサービス クラスを定義、適用する 2 つの主要なアプローチを用意しています。それぞれのアプローチで扱う基本的な要素には、許可するコールの種類(たとえば、local、national、または international)およびコールが取るパス(たとえば、IP ネットワーク、ローカル ゲートウェイ、または中央ゲートウェイ)が含まれます。どちらの要素もコーリング サーチ スペースを使用します。次の項では、Unified CM システムで使用される、サービス クラスを実装するための 2 つの主要なアプローチについて説明します。どちらのアプローチも回線とデバイスのコーリング サーチ スペースの基本的な機能に基づいています。

デバイスのコーリング サーチ スペースは、電話機の IP アドレスで定められているように、ネットワークのどの場所に電話機が物理的に存在しているか、デバイス モビリティが設定されているかどうかに基づいて動的に特定できます。詳細については、「デバイス モビリティ」を参照してください。

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

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

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

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

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

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

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

 

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

パスの選択

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

サービス クラス

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

結果として、このアプローチを集中型呼処理のマルチサイト配置に適用する場合は、パーティションとコーリング サーチ スペースを各サイトに複製する必要があります。これは、図 9-15 に示すように、サイトごとにサービス クラスを作成し、同時に、ローカル支店ゲートウェイから発信される PSTN コールをルーティングする必要があるためです。または、標準ローカル ルート グループを参照するルート リストを指すルート パターンを設定できます。こうすると、実際の出口ゲートウェイが、発信電話機のデバイス プールによって決定されます。これにより、コール ルーティングのサイト特性を保持しながら、サイト間のパターンを再利用できます。

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

 

集中型呼処理を行う複数サイト配置に対してこのダイヤル プラン アプローチを適用するときに、サイト間でオンネット ダイヤリングを構成するために、すべての IP Phone の DN をすべてのサイトのコーリング サーチ スペースからアクセス可能なオンクラスタまたは内部のパーティションに置きます。これは、IP Phone の DN が重複している場合は不可能であることに注意してください。

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

 

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

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

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

ルート パターンを使用した場合、エンド ユーザは番号を最後までダイヤルでき、ダイヤルが完了して初めてユーザにファストビジー トーンが再生されます。

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

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

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

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

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

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

 

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

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

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

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


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



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


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

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

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

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

表 9-8 フランス国内番号計画に適用される回線/デバイス アプローチ

コーリング サーチ スペース
パーティション
ブロック ルート パターン

Internal_css

BlockAllNational_pt

0.0[1-6]XXXXXXXX

BlockIntl_pt

0.00!、0.00!#

Local01_css

BlockLD01_pt

0.0[2-6]XXXXXXXX

BlockIntl_pt

0.00!、0.00!#

Local02_css

BlockLD02_pt

0.0[13-6]XXXXXXXX

BlockIntl_pt

0.00!、0.00!#

Local03_css

BlockLD03_pt

0.0[124-6]XXXXXXXX

BlockIntl_pt

0.00!、0.00!#

Local04_css

BlockLD04_pt

0.0[1-356]XXXXXXXX

BlockIntl_pt

0.00!、0.00!#

Local05_css

BlockLD05_pt

0.0[1-46]XXXXXXXX

BlockIntl_pt

0.00!、0.00!#

LD_css

BlockIntl_pt

0.00!、0.00!#

Intl_css

NoBlock_pt

なし

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

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

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

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

Call Forward All 動作に対する回線/デバイス アプローチのガイドラインについては、「自動転送コーリング サーチ スペース」の項を参照してください。


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


グローバル化された番号とサービス クラス

コーリング サーチ スペースに対する回線/デバイス アプローチを使用しているシステム管理者は、エンドポイントの回線 CSS で使用されるブロック パターンがローカル化された形式だけではなく、グローバル化された形式のコールもブロックする可能性があることに注意してください。ローカル化された形式の番号は local、regional、national に分類されますが、グローバル化された形式は分類されません。これによりサービス クラスの不一致が生じます。直接ユーザ ダイヤリングはサービス クラスに従属するのに対して、不在履歴リストと着信履歴リストからのワンタッチ ダイヤリングは従属しません。

たとえば、カナダのオンタリオ州 Ottawa にローカル サービス クラスを作成するとします。Ottawa のすべてのローカル コールはエリア コード 613 と 819 に分類され、ローカル コーリングは 10 桁のダイヤリングを使用して実行されます。ローカル形式のユーザ入力のみが Ottawa の電話機で許可されている場合、9[2-9]XX[2-9]XXXXXX の形式で行われたコールのみを許可することにより、「ローカル」サービス クラスを電話機に適用できます。国内の(長距離)宛先に行われたすべてのコールは、国際電話(9 の後に 011)のように、異なるダイヤリング形式(オフネットのアクセス コード 9 の後に国内振り分けコード 1、その後に番号)で始まります。コールの形式によりクラスが定義されます。

ワンタッチ ダイヤルを実行する場合、電話機のダイヤル プランでローカル番号のグローバル形式が許可されます。サービス クラスが回線コーリング サーチ スペースによって処理されるブロック パターンで実装された回線/デバイス アプローチに基づくダイヤル プランの場合、これは、一連のブロック パターンを実装してエリア コード 613 と 819 へのコールのみを許可する必要があることを意味します。たとえば、これを実現するには次のブロック パターンを使用します。

\+1[^68]!

\+16[^1]!

\+161[^3]!

\+18[^1]!

\+181[^9]!

通常は、最上位の数字および許可する番号ストリングが必要です。上記のブロック パターンでは、市内電話を不在履歴リストと着信履歴リストからワンタッチ ダイヤリングできます。

ただし、すべての 613 および 819 エリア コード宛先がローカル コールとなるわけではないので、さらに複雑です。ローカル化されたパターンにより、ユーザがローカル宛先に対してのみコールを開始することを許可された場合(ダイヤル ストリングの先頭で 9 819 または 9 613 とダイヤル)、グローバル化されたパターンでは、エリア コード 613 または 819 のローカル以外の番号からのコールの受信が許可され、受信コール リストに移動し、番号をワンタッチ ダイヤルで返し、グローバル化されたパターンと照合します。このような場合、ブロック パターンのグローバル形式は、ローカル コーリング エリアそのものを表すように修正する必要があります。上の例では、Ottawa のローカル コーリング エリア内のエリア コード 613 および 819 の正確なサブセットの定義を含みます。修正したブロック パターンは、ローカル コーリング エリアの構造によっては非常に複雑になる可能性があります。

また、これらの +E.164 ブロック パターンは、ローカライズされた形式とは異なり、サイト固有であり、他のサイトに再利用することはできません。回線コーリング サーチ スペースはこのサイト特性を継承するため、上記の例で Ottawa のサービス クラス「local」を実装するコーリング サーチ スペースは、Ottawa のサイトに固有です。これは、基本的には、すべてのサイトに対して普遍的に使用できるサイト固有ではないコーリング サーチ スペースを介してサービス クラスを作成することで、必要なコーリング サーチ スペースの数を減らす回線/デバイス アプローチの考え方全体に反します。

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

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

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

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

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

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

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

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

 

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

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

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

自動転送の考慮事項

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

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

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

 

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

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

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

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

サイト 1 の電話(電話機 A など)から発信されるコールは、サイト 1 のゲートウェイを通じて PSTN に正しく転送されます。

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

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

従来のアプローチとローカル ルート グループを使用した +E.164 ダイヤル プランのための Unified CM のサービス クラスの構築

回線/デバイス アプローチを使用してグローバル化された +E.164 ダイヤリングをサポートしようとすると、一部のサービス クラスでブロック パターンが必要になるため、回線コーリング サーチ スペースがサイト固有になるという問題が発生します。この場合、適切なブロック パターンを処理するサイト固有ではない回線コーリング サーチ スペースを使用して必要なコーリング サーチ スペースの数を最小限にするという回線/デバイス アプローチの設計目標が否定されます。そのため、従来のアプローチに勝る回線/デバイス アプローチの利点は、特に Unified CM 7.0 でローカル ルート グループの概念が採用されてからはわずかなものになりました。ローカル ルート グループを使用すると、管理者はサイト固有の出力ゲートウェイの選択を、ルート パターンから発信側デバイス固有のローカル グループの選択に移動できます。この選択プロセスでは、発信側デバイスのデバイス プールに設定されているローカル ルート グループが使用されます。

このアプローチの主な違いは、有効なサービス クラスが回線上のデバイス ブロック パターンでルート パターンを組み合わせた結果ではなく、単一のサービス クラス固有のコーリング サーチ スペースによって処理されたパターンの直接の結果であるという点です。(図 9-20を参照)。

図 9-20 +E.164 ダイヤル プランの「International」サービス クラス

 

図 9-20 に、米国の単一サイトのサービスクラス「international」を実装する例を示します。この概念では、ローカル ダイヤリング手順がパーティション SJCIntra、SJCtoE164local、および UStoE164International でトランスレーション パターンによって +E.164 に正規化されています。

パーティション SJCIntra でのトランスレーションでは、サイトのすべてのローカル DID が +1 408 555 1XXX の範囲内であると想定して、4 桁のサイト内ダイヤリングが実装されています。San Jose のサイトのローカル ダイヤリング(9+7)は、パーティション SJCtoE164local のトランスレーション パターンによって、ローカル ダイヤリング手順を +E.164 に変換することで実装されています。海外と国内の宛先に対する米国の PSTN ダイヤリング手順のグローバル化を実装するパーティション UStoE164International にも、同じことが当てはまります。

ここで使用されている命名規則は、複数のサービス クラス、サイト、およびダイヤリング ドメインをサポートするために複製する必要があるダイヤル プランを特定するのに役立ちます。名前にサイトの指定(たとえば、パーティション名 SJCE164Local の SJC)が含まれている場合は、すべてのサイトについてこの要素を複製する必要があります。名前にサービス クラスの指定(たとえば、USE164International の International)が含まれている場合は、すべてのサービス クラスについてこの要素を複製する必要があります。名前にサイトの指定が含まれていない場合は(たとえば、パーティション USPSTNNational)、すべてのサイトで再利用できます。

要求されたサービス クラスを作成する単一のコーリング サーチ スペースは、回線/デバイス コーリング サーチ スペースとして使用できます。エクステンション モビリティやデバイス モビリティなどのモビリティ機能をサポートする配置では、回線コーリング サーチ スペースを使用してユーザがローミング時にサービス クラスを保持できるようにする必要があります。

+E.164 以外のディレクトリ番号の使用

上記の例では、ローカル ダイヤリング手順を +E.164 に正規化した後にディレクトリ番号を直接照合できるように、すべてのディレクトリ番号が +E.164 として設定されていることを想定しています。ディレクトリ番号が +E.164 として設定されていない場合は、内部の +E.164 ルーティングから設定済みの DN の形式に再度マッピングするために中間のルーティング ステップが必要です。(図 9-21を参照)。

図 9-21 +E.164 以外のディレクトリ番号の間接的なサポート

 

図 9-21 に示す間接的ステップで +E.164 以外の形式のすべてのディレクトリ番号に到達するには、ローカル手順形式または +E.164 をダイヤルします。この場合のパーティション DN には実際のディレクトリ番号は保持されませんが、すべてのオンネット DID 範囲に一致する一連の緊急トランスレーション パターンは保持されます。たとえば、サイトで DID 範囲 +1 408 555 1XXX が使用され、ディレクトリ番号が先頭の + がない E.164 として設定されている場合は、ドットの前の番号を破棄するように数字破棄命令を設定して緊急トランスレーション パターン \+.14085551XXX をパーティション DN に作成する必要があります。これで、内線番号が +1 408 555 1234 であるユーザに、他のユーザからコーリング サーチ スペースを使用して到達できるようになります。この例では、次の番号をダイヤルします。

1234:ダイヤルされた番号は、パーティション SJCIntra のトランスレーション パターンによって +14085551234 に変換され、パーティション DN のトランスレーション パターン +14085551XXX によって 14085551234 に変換されます。次に、パーティション nonE164DN でディレクトリ番号と一致します。

95551234:ダイヤルされた番号は、パーティション SJCtoE164local のトランスレーション パターンによってグローバル化され、コール フローは 4 桁のサイト内ダイヤリングの場合と同じになります。

914085551234:ダイヤルされた番号は、パーティション UStoE164International のトランスレーション パターンによってグローバル化され、コール フローは 4 桁のサイト内ダイヤリングの場合と同じになります。

+14085551234:パーティション DN のトランスレーション パターン +14085551XXX によって 14085551234 に変換され、パーティション nonE164DN でディレクトリ番号と一致します。

+E.164 以外のディレクトリ番号を使用する場合は、正しい発信者情報をすべてのコール フローで配信できるように、これらの回線から発信されたコールの発呼側番号を +E.164 に設定する必要があります。そのためには、すべてのライン アピアランスについて外部電話番号マスクを +E.164 に設定し、その外部電話番号マスクを使用するようにパーティション DN のトランスレーション パターンの発信側トランスフォーメーションを設定します。+E.164 以外のディレクトリ番号をグローバル化する別の方法は、電話機または電話機のデバイス プールで着信コールの発信側トランスフォーメーション コーリング サーチ スペースを使用することです。この方法は、Cisco Unified CM 9.0 以降のリリースでサポートされ、ディレクトリ番号をグローバル化するための推奨方法です。このコーリング サーチ スペースに基づくグローバル化を使用すると、トランスレーション パターンに設定された番号トランスフォーメーションを適用できない URI ダイヤル コール フローも処理できるという利点が得られます。

ディレクトリ番号と国際 PSTN ダイヤリングの重複

Unified CM のディレクトリ番号は、常に非緊急パターンとして番号分析に格納されます。これにより、国際オンネット宛先をダイヤルすると、国際 PSTN ルート パターン \+[^1]! と部分的に重複する場合があります。たとえば、San Jose のユーザが +496100773 をダイヤルし、それがシステムに設定されているディレクトリ番号であった場合、追加の間接的ステップ(図 9-20)を実施せずにスキーマを使用するコールは、桁間タイムアウト制限に達します。これは、ディレクトリ番号 \+496100773 に一致するものがあっても、可変長パターン \+[^1]! に一致する可能性のあるものがパーティション PSTNInternational に存在するためです。これを回避するには、オンネット ディレクトリ番号があるすべての国について、特定の緊急固定長ルート パターンを PSTNInternational パーティションに追加します。PSTNInternational パーティションの緊急ルート パターンは番号収集を終了しますが、Unified CM はコールを最適な一致(この例ではパーティション DN のディレクトリ番号)にルーティングします。このアプローチは、固定長の国内番号計画を持つ国でのみ使用できます。国内番号計画が可変長の番号計画である場合(ドイツなど)、ディレクトリ番号と可変長の PSTN ルート パターンの重複を解決する唯一の方法は、図 9-21 に示されている中間ルーティング ステップを実装することです。この場合、パーティション DN の緊急トランスレーション パターンは、緊急パターンを番号分析に追加して既知のオンネット宛先がダイヤルされるとすぐに番号収集が終了することを確認するという目的に適合します。

その他のサービス クラス

図 9-20図 9-21 の例に基づき、「national」や「local」などの他のサービス クラスは、不要な PSTN ルート パターンを削除し、ローカル ダイヤリング手順のダイヤリング正規化を再作成することによって作成します。(図 9-22 を参照)。

図 9-22 +E.164 ダイヤル プランの「National」サービス クラス

 

図 9-22 に、サービス クラス「national」の構築方法を示します。この方法を図 9-20 のサービス クラス「international」と比較すると、パーティション SJCIntra、SJCtoE164local、USPSTNNational、および SJCPSTNLocal を再利用でき、コーリング サーチ スペース DN と SJCE164Local も再利用できます。図 9-20 のパーティション UStoE164International のパターンによって定義されたダイヤリング正規化を使用すると、国際 PSTN ルート パターン \+[^1] へのアクセスも許可されるため、USToE164National のダイヤリングの正規化を再作成する必要があります。これは、トランスレーション パターンの定義で、トランスレーション パターンに定義されている着信側と発信側のトランスフォーメーションの適用後に使用する必要がある単一のコーリング サーチ スペースを定義した結果です。コーリング サーチ スペースはサービス クラスに相当するため、トランスレーション パターンは、トランスレーション パターンに定義されている出力コーリング サーチ スペースのサービスクラス特性を継承します。したがって、サービス クラス固有にもなります。

パーティション UStoE164National のダイヤリング正規化には、国際ダイヤリング 9011 のローカル手順のダイヤリング正規化パターンが含まれていません。これは、国際オンネット宛先(米国外のパーティション DN のディレクトリ番号)への国際ダイヤリングをサポートする必要があるためです。

サービス クラス「local」と「internal」は、同じアプローチで作成できます。パーティション SJCPSTNLocal は、実際にはサービス クラス「international」を作成するために必要ではありませんが、この区別された PSTN アクセスを最初から提供すると、サービス クラス「local」にパーティション SJCPSTNLocal と SJCtoE164Local を再利用できます。パーティション SJCPSTNLocal は、PSTN へのアクセスを提供しないサービス クラス「internal」には再利用できないということに留意してください。このサービス クラスについては、ローカル ダイヤリングのダイヤリング正規化を図 9-23 に示すように複製する必要があります。

図 9-23 +E.164 ダイヤル プランの「internal」サービス クラス

 

緊急コール

緊急サービスへのアクセスは、すべてのユーザに許可する必要があります。そのためには、緊急番号ルート パターンのパーティションを各コーリング サーチ スペースに追加するか、デバイスレベルのコーリング サーチ スペースを介した緊急番号ルート パターンへのアクセスを有効にします。デバイス コーリング サーチ スペース経由の緊急番号へのアクセスが許可されている場合は、ローミング シナリオ(たとえば、エクステンション モビリティ)において、ユーザは訪問したサイトのダイヤリング手順を使用して、緊急サービスをダイヤルする必要があります。一方、回線コーリング サーチ スペース経由の緊急番号へのアクセスの場合、ユーザはホーム サイトのダイヤリング手順を使用して緊急サービスをダイヤルできます。この違いが明らかに重要になるのは、ホーム サイトと訪問したサイトで緊急サービスのダイヤリング手順が異なる場合のみです。たとえば、欧州のユーザ(緊急番号 112)が米国の電話機(緊急番号 911)にログインする場合などです。

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

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

集中型呼処理を使用する Cisco Unified CM マルチサイト配置

Cisco Unified Communications Manager Express(Unified CME)配置

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

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

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

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

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

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

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

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

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

 

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


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

dial-peer cor custom
name Emergency
name VMail
name Local
name LD
name Intl
 

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

dial-peer cor list EmPt
member Emergency
 
dial-peer cor list VMailPt
member VMail
 
dial-peer cor list LocalPt
member Local
 
dial-peer cor list LDPt
member LD
 
dial-peer cor list IntlPt
member Intl
 

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

dial-peer cor list InternalCSS
member Emergency
member VMail
 
dial-peer cor list LocalCSS
member Emergency
member VMail
member Local
 
dial-peer cor list LDCSS
member Emergency
member VMail
member Local
member LD
 
dial-peer cor list IntlCSS
member Emergency
member VMail
member Local
member LD
member Intl
 

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

dial-peer voice 100 pots
corlist outgoing EmPt
destination-pattern 911
no digit-strip
direct-inward-dial
port 1/0:23
 
dial-peer voice 101 pots
corlist outgoing VMailPt
destination-pattern 914085551234
forward-digits 11
direct-inward-dial
port 1/0:23
 
dial-peer voice 102 pots
corlist outgoing LocalPt
destination-pattern 9[2-9]......
forward-digits 7
direct-inward-dial
port 1/0:23
 
dial-peer voice 103 pots
corlist outgoing LDPt
destination-pattern 91[2-9]..[2-9]......
forward-digits 11
direct-inward-dial
port 1/0:23
 
dial-peer voice 104 pots
corlist outgoing IntlPt
destination-pattern 9011T
prefix-digits 011
direct-inward-dial
port 1/0:23
 

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

call-manager-fallback
cor incoming InternalCSS default
cor incoming LocalCSS 1 3001 - 3003
cor incoming LDCSS 2 3004
cor incoming IntlCSS 3 3010
 


 

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 Communications Manager Express(Unified CME)配置にも同じ概念を適用できます。ただし、次の考慮事項があります。

Unified CME を使用している場合は、サービス クラスを表現している COR リスト(コーリング サーチ スペースに相当するもの)を個々の IP Phone に直接割り当てることができます。割り当てるには、 cor { incoming | outgoing } corlist-name コマンドを ephone-dn dn-tag コンフィギュレーション モードで使用します。

COR リストの設定されていない IP Phone は、COR の一般規則に従って、発信 COR リストの内容に関係なくすべてのダイヤル ピアに無制限にアクセスできます。Unified CME は、すべての電話にデフォルトの制限を適用する、 cor incoming corlist-name default コマンドに相当するメカニズムを備えていません。

コール カバレッジの配置

コール カバレッジ機能は、多くの IP テレフォニー配置で重要となる機能です。顧客サービスを重視する多くの企業では、顧客のコールを適切なサービス部門に迅速にルーティングすることが必須になります。この項では、ハント パイロット、ハント リスト、および回線グループに基づいたハンティング メカニズムを使用して、Cisco Unified CM Release 4.1 でコールを分配する場合の設計ガイドラインを中心に説明します。ここでは、次のトピックを主に扱います。

「マルチサイト集中型呼処理モデルへのコール カバレッジの配置」

「マルチサイト分散型呼処理モデルへのコール カバレッジの配置」


) コール カバレッジ機能自体はコール キューを提供せず、発信側には、コールの宛先が見つかるまでリングバック トーンが送信されます。プロンプトや保留音などを提供するため、シスコでは Cisco Unified Customer Voice Portal(CVP)などの多数のコンタクト センター テクノロジーを用意しています。シスコから入手可能なコンタクト センター テクノロジーの詳細については、http://www.cisco.com/go/ucsrnd で入手可能な資料を参照してください。


マルチサイト集中型呼処理モデルへのコール カバレッジの配置

図 9-25 では、マルチサイトの集中型呼処理配置における、ハント リストの設定例を示しています。この例では、最初にリモート オフィスのオペレータを通じてハント パイロット コールが分配されることを前提としています。コールは、応答されなかった場合やコール アドミッション制御によって拒否された場合、中央サイトのオペレータまたはボイスメールにルーティングされます。

図 9-25 集中型呼処理配置における複数のサイト間でのコール カバレッジ

 

集中型の IP テレフォニー システムでは、や Survivable Remote Site Telephony(SRST)などの機能を有効にすることで、高い可用性を実現できます。AAR 機能や SRST 機能を有効にしたうえでコール カバレッジ機能を配置する場合は、次のガイドラインを考慮してください。

自動代替ルーティング(AAR)

回線グループのメンバーは、複数のロケーションおよびリージョンに割り当てることができます。ロケーションを通じて実装したコール アドミッション制御は、想定どおりに動作します。ただし、ハント パイロットから分配されているコールは、WAN の帯域幅が不足していたためにいずれかの回線グループ メンバーへのコールが Unified CM によってブロックされた場合には、AAR を使用して再ルーティングされることはありません。代わりに、Unified CM はコールを使用可能な次のメンバーまたは回線グループに分配します。


) AAR のみを使用する場合は、回線グループ内でボイスメール ポートを使用することを強く推奨します。


Survivable Remote Site Telephony(SRST)

Unified CM がハント パイロットのコールを受信したとき、その回線グループ メンバーの一部が、SRST モードで動作しているリモート サイトにある場合、Unified CM はそれらのメンバーをスキップし、使用可能な次の回線グループ メンバーにコールを分配します。Unified CM から見ると、SRST モードで動作しているメンバーは未登録であり、ハント パイロットのコールは未登録メンバーには転送されません。

SRST モードで動作しているルータがハント パイロットのコールを受信したときは、コール カバレッジ機能を使用できません。このコールは、使用可能な登録済み内線番号にコールを再ルーティングする設定が追加されていない場合、失敗します。 alias コマンドまたは default-destination コマンドを Cisco IOS の call-manager-fallback モードで使用すると、ハント パイロットを宛先とするコールをオペレータ内線またはボイスメールに再ルーティングできます。

マルチサイト分散型呼処理モデルへのコール カバレッジの配置

Cisco Unified CM Release 4.1 以降では、ルート グループをハント リストに追加することができなくなりました。このため、ハント リストを使用して、コールを他のクラスタまたはリモート ゲートウェイに送信することはできません。ただし、Cisco Unified CM Release 4.1 で導入されたハント パイロットのハント オプション設定を使用して、ゲートウェイまたはトランクを指すルート パターンに対応付けることができます。

図 9-26 は、クラスタ間トランクを使用する分散型呼処理配置における、ハント リストの設定例を示しています。この例では、ハント パイロットのコールが最初にクラスタ A の内部に配置されます。コールに対する応答がない場合は、ルート パターンに一致する Forward Hunt No Answer 設定を使用して、コールがコール分配のためにクラスタ B に再ルーティングされます。このルート パターンは、クラスタ B に向かうクラスタ間トランクを指しています。

図 9-26 分散型呼処理配置におけるクラスタ間でのコール カバレッジ

 


ヒント 分散型呼処理配置では、Cisco VoIP ゲートウェイとゲートキーパーを使用して、着信するハント パイロット コールのロード シェアリングを管理できます。あるクラスタ内でコールに応答がなかった場合は、そのコールを別のクラスタにオーバーフローしてサービスを提供できます。コールは、ゲートウェイまたはトランクを通じて IVR 処理に送信することもできます。Tool Command Language(TCL)IVR アプリケーションは、Cisco IOS ゲートウェイ上に実装できます。

ガイドライン

コール カバレッジ機能を分散型呼処理モデルに配置する場合、コールが複数のクラスタに分配されると、ルート パターンは発信または着信のルート グループ デバイス上で実行される番号変換を考慮に入れて、ルート パターンを適切に設定する必要があります。番号変換が実行されない場合、設定するルート パターンとハント パイロットは、すべてのクラスタ上で同一にする必要があります。同一でない場合は、コールが適切に分配されません。

ハント パイロットのスケーラビリティ

トップダウン、循環、および最長アイドル時間の各アルゴリズムを使用してコール カバレッジを配置する場合は、次のガイドラインを参考にすることを推奨します。

Unified CM クラスタは、最大で 15,000 のハント リスト デバイスをサポートします。

ハント リスト デバイスは、1,500 個のハント リストそれぞれに 10 台の IP Phone を入れた組み合わせにすることも、750 個のハント リストそれぞれに 20 台の IP Phone を入れた組み合わせにすることもできます。


) コール カバレッジにブロードキャスト アルゴリズムを使用する場合、ハント リスト デバイスの数は、Busy Hour Call Attempts(BHCA)の数によって制限されます。ブロードキャスト アルゴリズムを使用して、10 台の電話機を含むハント リストまたはハント グループを指すハント パイロットに対して 10 回の BHCA を行うことは、10 回の BHCA を行う 10 台の電話機と同じです。


1 つの回線グループ内に、コールをすべての DN に同時に送信することを目的として設定するディレクトリ番号の数は、最大で 35 までにすることを推奨します。また、ブロードキャスト回線グループの数は、BHCC によって決まります。Unified CM システム内に複数のブロードキャスト回線グループがある場合、回線グループ内のディレクトリ番号の数は、35 よりも少なくする必要があります。すべてのブロードキャスト回線グループの最繁時呼数(BHCA)の数が、1 秒あたり 35 コール セットアップを超えないようにします。

Directory URI ダイヤリングの配置

Cisco Unified CM 9.0 から、英数字のディレクトリ ユニフォーム リソース識別子(URI)のプロビジョニングとダイヤリングが Unified CM でサポートされました。SIP URI を処理するとき、Unified CM コール ルーティングは数字 SIP URI と英数字 SIP URI を識別します(「Unified CM での SIP 要求のルーティング」を参照)。Unified CM に登録されているエンドポイントの場合、これは新しいダイヤリング手順として Directory URI へのダイヤルを追加します。また、Directory URI に基づく発信者 ID は、Unified CM に登録されたデバイスから発信されるコールにとって新しい概念です。

大文字と小文字の区別

RFC 3261(section 19.1.4、「URI Comparison」)によれば、SIP URI のユーザ情報比較は大文字と小文字を区別する必要があります。この標準化された動作によれば、Alice@cisco.com と alice@cisco.com を等価と考えるべきではありません。 Directory URI のルーティングでは、Unified CM はこの標準に従い、ユーザ部分では大文字と小文字を区別した完全一致検索、ホスト部分では大文字と小文字を区別しない検索を行います。混乱を避けるため、Directory URI だけはすべて小文字のユーザ情報を入力して、すべて小文字の情報を入力すれば確実にダイヤルされるようにプロビジョニングすることを強く推奨します。

Unified CM 9.1 以降のリリースでは、Directory URI のユーザ情報部分について、常時大文字と小文字を区別しないで比較するよう設定できます。これは、エンタープライズ パラメータ URI Lookup Policy を相応に設定することで実現できます。この設定は、ローカルに設定された Directory URI のマッチングに加え、ILS ルックアップが実行される Directory URI のマッチングにも適用されます。このエンタープライズ パラメータのデフォルト設定は、Directory URI のユーザ情報部分について、大文字と小文字を区別する標準準拠のマッチングを定義します。

独立コール ルーティング

Directory URI が Unified CM によってルーティングされる場合、ダイヤルされた Directory URI は、発信デバイスのコーリング サーチ スペースによって提示された、設定されたローカル Directory URI に対して最初に直接一致したものになります。大文字小文字を含めた完全一致があれば、コールはダイヤルされた宛先に直接拡張されます。(図 9-27 を参照)。

図 9-27 数字ダイヤリングと Directory URI ダイヤリングの独立ルーティング

 

図 9-27 の例では、ディレクトリ番号がアクセスコード(8)、3 桁のサイト コード(496)、および 4 桁の内線番号(9123、9764)からなる 8 桁のエンタープライズ番号計画を使用して設定されたと仮定しています。4 桁のサイト内ダイヤリングをイネーブルにするため、着信側番号変換マスク 84969XXX を適用することで着信側番号を必要な 8 桁のシーケンスに変換するトランスレーション パターン 9XXX が存在します。

図 9-27 の右側の電話に到達するために、左側の電話機を使用するユーザは 9764 または carol@cisco.com をダイヤルします。ユーザが 9764 とダイヤルすると、トランスレーション パターンに一致し、着信側は 84969764 に変換され、コーリング サーチ スペース DN を使用して、コールはパーティション DN 内のディレクトリ番号 84969764 に到達します。一方、Directory URI「carol」がダイヤルされると、コールはディレクトリ番号 84969764 に直接到達します。パーティション DirectoryURI 内の Directory URI carol@cisco.com が、コーリング サーチ スペース PhoneCSS を使用して直接見つかるためです。この相違は、ダイヤリング正規化トランスレーション パターン 9XXX が、着信側番号の変換だけでなく、発呼側番号の変換にも適用される場合に重要になります。トランスレーション パターン 9XXX の場合、通常の数値ダイヤル プランでは、このコールの発呼側番号情報がグローバルな +E.164 形式で送信されるようにするために発呼側番号変換を実行する場合があります。これを実現するため、通常 DN に外線電話番号マスクが設定され、トランスレーション パターンの発呼側番号変換を「 発呼側の外線電話番号マスクを使用 」に設定します。この状況では、左側の電話機から右側の電話機へのコールの発信者 ID は、コールの発信に使用するダイヤリング手順によって異なります。コールが 9764 をダイヤルして送信された場合、右側で表示される発信者 ID は左側の電話機の正しい +E.164 発信者 ID に基づいたものになりますが、carol@cisco.com としてダイヤルされたコールでは、84969123 に基づいたコール ID になります。これは、トランスレーション パターンの発信者変換が適用されないためです。

これを避けるため、電話機からのコールの発信者正規化を、トランスレーション パターンから電話機またはデバイス プール上の着信コールの発信者変換コーリング サーチ スペースに移行することを強く推奨します。

Unified CM の追加ダイヤリング手順として、Directory URI ダイヤリングをイネーブルにする場合、数値ダイヤルされたコールとディレクトリによるコールが別々にルーティングされるということを考慮に入れる必要があります。上記の矛盾した発信者 ID 配信の問題は、発信側電話機または発信側電話のデバイス プールの着信コールの発信者変換コーリング サーチ スペース(Unified CM 9.0 で導入)を使用して、簡単に対処できます。既存の企業ダイヤル プランのトランスレーション パターンには、簡単に対処できない他のさまざまな目的が存在する可能性があります(コール ブロッキングや宛先依存発信者 ID マスキングなど)。シスコでは、トランスレーション パターンなどの中間ルーティング ステップの存在について既存のダイヤル プランを確認し、それらの中間ルーティング ステップの役割を理解することを推奨します。Directory URI ダイヤリングでは、中間ルーティング ステップによって作成される既存の動作を再現できない場合があるからです。

Directory URI 用サービス クラスの構築

Unified CM のパーティションは、同じ到達可能性に属する接続先をグループ化するために使用されます。たとえば、特定の部門ごとにユーザへの到達可能性を変えるためのサービス クラスを実装する必要がある場合、販売部門のディレクトリ番号はすべて 1 つのパーティションに存在し、技術部門のディレクトリ番号はさまざまなパーティションに存在する可能性があります。

ディレクトリ番号に関連付けられた手動設定済み Directory URI はどのパーティションに置くことも可能です。関連付けられたディレクトリ番号と同じパーティションに存在する必要はありません(選択肢の 1 つでしかありませんが)。

内線番号に関連付けられた Directory URI すべては、Directory URI とエンドユーザに設定されたプライマリ内線に基づいて、常に自動的に単一のパーティション Directory URI 内に作成されます。さまざまな到達可能性が必要な場合、この Directory URI パーティションは使用できません。代わりに、必要とされる制限付きサービス クラスの作成に使用できるよう、すべてのユーザの Directory URI を正しいパーティションにプロビジョニングする必要があります。図 9-28 に、Engineering と Sales の 2 つの部門の例を示します。同じパーティションに存在しない限り、重複した複数の Directory URI が Unified CM に存在できます。

図 9-28 Directory URI 用サービス クラスの構築

 

Directory URI パーティションのエイリアス

ユーザ グループの区別が(セクション「Directory URI 用サービス クラスの構築」を参照)必要ない単純な配置では、自動的に作成された Directory URI の到達可能性は、通常すべてエンドユーザ ディレクトリ番号の到達可能性と同等です。フラット アドレッシングと可変長のオンネット ダイヤリング(VLOD)に基づいた設計では、すべてのエンドユーザ ディレクトリ番号が 1 つのパーティションに存在します。自動的に作成された Directory URI すべてを既存のダイヤル プランで到達可能にするために、Directory URI パーティションを適切なコーリング サーチ スペースに追加する必要があります。Directory URI パーティションを追加するのに正しい場所を選ぶようにします。Directory URI パーティションを扱うコーリング サーチ スペースは、発呼回線や発呼デバイスに直接割り当てられたコーリング サーチ スペースである必要があります。直接割り当てられていないもののトランスレーション パターンのヒット後にのみ使用されるコーリング サーチ スペースは、有効なオプションではありません。Directory URI ダイヤリングがトランスレーション パターンにマッチすることはないからです(「独立コール ルーティング」の項を参照)。

多数のコーリング サーチ スペースを変更する代わりに、Unified CM では Directory URI パーティションにエイリアス パーティションを定義できます。これは、エンタープライズ パラメータ Directory URI Alias Partition を、エイリアスとして使用される既存のパーティションに設定することで実現します。既存のパーティションを Directory URI エイリアス パーティションとして選択することにより、選択されたエイリアス パーティションにアクセスできるすべてのコーリング サーチ スペースは自動的に Directory URI パーティションにもアクセスできるようになります。

図 9-29 では、Directory URI エイリアス パーティションとしてパーティション DN がよい選択肢になります。すべてのディレクトリ番号を保持する DN パーティションにアクセスできるデバイスはすべて、それらのディレクトリ番号に関連付けられた Directory URI にもアクセス可能である必要があるからです。

図 9-29 +E.164 ダイヤル プランの「International」サービス クラス

 

図 9-30 では、パーティション nonE164DN が有効な Directory URI エイリアス パーティションではないことに注意してください。パーティション nonE164DN はすべてのディレクトリ番号を保持しますが、このパーティションはどのデバイスからも直接アクセスできないため、Directory URI をダイヤルしても機能しません。図 9-30 では、実際のディレクトリ番号を含んでいないパーティションですが、パーティション DN がよい選択肢です。

図 9-30 +E.164 以外のディレクトリ番号の間接的なサポート

 

混合 ID

Unified CM では、ライン アピアランスのプライマリ ID は常に数値(頭に + が付く場合あり)ディレクトリ番号です。Directory URI は、常にこれらの数値ディレクトリ番号のエイリアスとして設定されます。Directory URI がディレクトリ番号に関連付けられるとすぐ、数値ディレクトリ番号と最初に関連付けられた Directory URI という 2 つの ID が存在するようになります。これらの 2 つの部分の組み合わせは、 混合 ID と呼ばれます。

関連付けられた Directory URI を持つディレクトリ番号が関係するコールのそれぞれについて、Unified CM は混合 ID のうちどちらを使用し、どちらをコールに関係するエンドポイントやトランクに提示するかを決定する必要があります。この決定は、含まれるエンドポイントやトランクの機能によって決まります。エンドポイントが Unified CM に登録されていることは、登録のときに Directory URI ベースの発信者 ID を扱うことができるかどうかを示します。

登録時に Directory URI のサポートを示すエンドポイントの場合、Unified CM は常に Directory URI ベースの発信者 ID の送信を試行します。Directory URI ダイヤリングおよび発信者 ID をサポートしていないデバイスからのコールの場合でも、Unified CM は発信ディレクトリ番号のプライマリ Directory URI を Directory URI ベースの発信者 ID として使用できます。

SIP トランクの場合、トランクに送信される発呼側番号と接続先情報のフォーマットは、トランク上の新しい Calling and Connected Party Info Format 設定によって定義されます。この設定のデフォルトでは、常に数値 ID のみを送信します。これは、リリース 9.0 よりも前の Unified CM の動作との下位互換性を保証するためです。別の方法として、ID が常に Directory URI としてのみ送信される(使用可能な場合)ようにトランクを設定できます。3 つ目のオプションは、常に混合 ID の両方の部分(Directory URI と数値ディレクトリ番号)を送信することです。シスコでは、複数の Unified CM を相互接続する場合、この 3 つ目のオプション(Directory URI と数値 ID)を使用することを推奨します。この設定は、リモート クラスタが常に混合 ID 全体を取得できるようにし、リモート エンドポイントにどちらを提示するかをそのエンドポイントの機能に基づいて決定するようにします。

ダイヤル プランの要素

この項では、Cisco Unified Communication システムに含まれている次のダイヤル プラン要素について、設計と設定のガイドラインを示します。

「SCCP 電話機でのユーザ入力」

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

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

「SIP ダイヤル規則」

「Unified CM におけるコール ルーティング」

「Unified CM におけるコール特権」

「トランスレーション パターン」

「Automated Alternate Routing(自動代替ルーティング)」

「デバイス モビリティ」

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

「即転送(iDivert)」

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

「時間帯ルーティング」

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

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

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

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

IP Phone でのユーザ インターフェイス

さまざまな種類の IP 電話で、キーパッド入力が使用でき、視覚的な情報をさまざまな方法で提供します。この章では説明のため、次のタイプの電話機を定義します。

タイプ A 電話機:Cisco Unified IP Phone 7905、7912、7940、および 7960

タイプ B 電話機:Cisco Unified IP Phone 6901、6911、6921、6941、6945、6961、7906、7911、7921、7925、7931、7941、7942、7945、7961、7962、7965、7970、7971、7975、8961、9951、および 9971

IP Phone での発信側の変換

発信者トランスフォーメーション パターンによって、システムは発呼側番号をさまざまな形式に適応させることができます。最も一般的な用途は、グローバル化された発呼側番号からローカライズされた番号に適応させること、およびその逆です。

トランスフォーメーション パターンは、照合される発呼側番号の数値表現で構成されます。使用される構文は、ルート パターン、トランスフォーメーション パターン、ディレクトリ番号などのその他パターンの構文と同じです

変換演算子には、数字破棄命令(ドット前の番号など)、発信側トランスフォーメーション マスク、プレフィックス番号が含まれます。この演算子によって、発信側電話番号表示(Default、Allowed、または Restricted)が制御されます。発信側トランスフォーメーション パターンを設定することで、発信側の外部電話番号マスクを発呼側番号として使用できます。

パーティションおよびコーリング サーチ スペースによって、どの発信側トランスフォーメーション パターンをどの電話機に適用するかどうかが制御されます。電話機では、デバイス プールの発信側トランスフォーメーション コーリング サーチ スペース(CSS)またはデバイス固有の発信側トランスフォーメーション CSS を優先順位の低い順に使用できます。電話機に送信されるコールは、着信側トランスフォーメーション パターンを使用して処理されるのではありません。

IP 電話機では、発信側変換を電話機から発信されたコールと電話機で終了したコール用に設定できます。

設定されたディレクトリ番号がグローバル化された番号(+E.164)形式ではない電話から発信されたコールの場合、着信コールの発信側変換 CSS を使用して適切なグローバル化を定義できます。Unified CM 9.1 以降のリリースでは、この CSS は [Number Presentation Transformation] セクションの [Phone Configuration] ページ、または [Caller ID For Calls From This Phone] の下の [Device Pool Conficuration] にある [Phone Settings] セクションにあります。

電話機で終了したコールについては、発信コールの発信側変換 CSS を使用して、発呼側番号に適用するローカリゼーション方式を定義できます。Unified CM 9.1 以降のリリースでは、この CSS は [Remote Number] の下の [Number Presentation Transformation] セクションの [Phone Configuration] ページにあります。

電話機の場合、電話が鳴っている間に表示される番号が、発信またはリモート番号の発信側変換の影響を受けます。

タイプ B 電話機の場合、不在コールと受信コールのディレクトリ内の対応するエントリは、変換された番号と変換前の元の番号の両方を保持します。変換された番号がディレクトリのリストに表示されますが、コールバックに使用される番号は変換前の番号です。

Unified CM Release 9.1 以降では、発信コールの発信側変換 CSS(ローカリゼーションやリモート番号の発信側変換 CSS とも呼ばれる)を使用して、リモート接続されている通話者情報をローカライズすることもできます。この機能をイネーブルにするには、拡張サービス パラメータ Apply Transformations On Remote Number をイネーブルにする必要があります。

ローカライズされた通話者情報を電話機に提供できることで、通話切換機能が呼び出された場合でも一貫したリモートの通話者情報を IP 電話機に表示できます。

電話機での + ダイヤリングのサポート

タイプ A 電話機では、キーパッドを使用して + 記号をダイヤルすることはできません。タイプ B 電話機では、0 キー(Cisco Unified IP Phones 7921 および 7925)または * キー(他のすべての電話機モデル)のいずれかを押したままにして + 記号をダイヤルできます。Cisco Unified Personal Communicator エンドポイントでは、+ 記号はコンピュータのキーボードを使用して入力するか、エンドポイントのクリックツーダイヤル機能の使用時に入力文字列の一部として入力します。

タイプ A の電話機では、+ 記号の表示はサポートされていません。

タイプ B の電話機および Cisco Unified Personal Communicator では、着信コールは + を番号の一部として発呼側番号として表示できます。コールが電話機に提供されたとき、呼び出し中の電話機に表示される番号は、設定された発呼側番号トランスフォーメーション パターンによって処理されます。不在コールと受信コールのディレクトリは、元の変換前の番号と変換された番号の両方を保持します。リストに表示される番号は変換された番号になり、変換前の番号はエントリの詳細を確認したときにだけ表示されます。ディレクトリからダイヤルされた番号は元の変換前の番号であり、発信番号の一部として + 記号が使用された以前の受信コールをワンタッチでダイヤルできるようになります。

例 9-1 + ダイヤリングを使用する発呼側番号

New York にあるタイプ B 電話機が +1 408 526 4000 からのコールを受信します。発信側トランスフォーメーション パターンは、電話機のデバイス プールの発信側変換 CSS に配置されています。パターンの 1 つは \+1.!(ドットの前の番号を削除)と設定されています。

コールが鳴ると、着信側電話機に着信側番号 4085264000 が表示されます。コールに応答し、コールを解放した後、受信コール ディレクトリには最後のコールが 408 526 4000 として表示されますが、ユーザがディレクトリ エントリからコールバックを開始したときの着信番号は +1 408 526 4000 です。

SCCP 電話機でのユーザ入力

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

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

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

 

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

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

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

タイプ A 電話機はタイプ B 電話機と動作が少し異なり、タイプ B 電話機では Key Press Markup Language(KPML)がサポートされていますが、タイプ A 電話機ではサポートされません (「タイプ B の SIP 電話機でのユーザ入力」を参照)。

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

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

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

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

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

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

 

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


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


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

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

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

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

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

 

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

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

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

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

タイプ B 電話機はタイプ A 電話機と動作が少し異なり、タイプ B 電話機では Key Press Markup Language(KPML)がサポートされていますが、タイプ A 電話機ではサポートされません (「タイプ A の SIP 電話機でのユーザ入力」を参照)。

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

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

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

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

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

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

 

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

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

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

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

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

 

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


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


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


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


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

SIP ダイヤル規則

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

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

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

7905_7912(Cisco Unified IP Phone 7905 および 7912 に使用)

7940_7960_OTHER(上記以外のすべての IP Phone モデルに使用)

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

パターン

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

パターン
ダイヤル規則のタイプ
7905_7912
7940_7960_OTHER

数字の 0 ~ 9

対応する数字。

対応する数字。

.

任意の数字(0 ~ 9)と一致します。

任意の文字(0 ~ 9、*、#)と一致します。

-

続けて追加の数字が入力される場合があることを示します。個々の規則の末尾に置く必要があります。

n/a

#

入力終了キー。ダイヤル規則の中に文字位置を示す > 文字を置くと、その文字位置以後は # キーが入力終了として認識されます。たとえば、9>#... と指定すると、9 が押された後は、いつでも # 文字が認識されます。

n/a

t n

n 秒のタイムアウト値を示します。たとえば、1...t3 は 1000 と一致し、3 秒後に Unified CM への Invite の送信をトリガーします。

n/a

r n

最後の文字を n 回繰り返します。たとえば、1.r3 は 1... に相当します。

n/a

S

パターンに修飾子 S が含まれていると、このパターン以後の他のダイヤル規則がすべて無視されます。実質的に、S によって規則照合が終了します。

n/a

*

入力終了キー。ダイヤル規則の中に文字位置を示す > 文字を置くと、その文字位置以後は * キーが入力終了として認識されます。

1 文字以上と一致します。たとえば、パターン 1* は 10、112、123456 などと一致します。

,

n/a

電話機でセカンド ダイヤル トーンを再生します。たとえば、8,.... と指定すると、 ユーザには 8 を押した後にセカンド ダイヤル トーンが聞こえます。

IButton

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

Timeout

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

User

このパラメータは、ダイヤルされた番号に自動的に追加されるタグを表します。有効な値は、 IP (Unified CM 以外の SIP コール エージェントが配置される場合)と Phone です。このパラメータは、7940_7960_OTHER ダイヤル規則にのみ適用されます。このパラメータはオプションであり、Unified CM が唯一のコール エージェントとなる配置では省略してください。Unified CM のリリース 9.0 以降に送信される SIP リクエスト内の user=phone タグは、SIP URI を数値 URI として扱うよう Unified CM に強制することに注意してください。alice@cisco.com;user=phone 形式の SIP URI のルーティングは成功しません。user=phone タグは数値扱いを強制し、alice は Unified CM にプロビジョニングされたどの数値パターンにもマッチしないからです。


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


SIP ダイヤル規則
7905_7912
7940_7960_OTHER

........
9.......

最初に一致するパターンの ........ が選択されます。

最長一致パターンの 9....... が選択されます。

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

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

Directory URI がダイヤルされたとき、Unified CM は完全一致ロジックを使用して、Directory URI ルーティング テーブル内の設定済み Directory URI から大文字と小文字を区別して一致を検索します。番号がダイヤルされると、Unified CM では closest-match ロジックを使用し、数字のコール ルーティング テーブルにあるすべてのパターンの中から一致パターンを選択します。一致する可能性のある数字パターンが複数ある場合は、次の基準に基づいて宛先パターンを選択します。

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

一致する可能性のあるパターンのうち、ダイヤルされたストリング以外に一致するパターンが最も少ないもの。

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

図 9-36 Unified CM のコール ルーティング ロジックの例

 

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

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

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


) Cisco Unified CM でディレクトリ番号(DN)を設定すると、それぞれのデバイス(IP Phone など)が登録済みかどうかにかかわらず、その番号はコール ルーティング テーブルに配置されます。この仕様によって、アプリケーション(およびそのプライマリ パターン)が未登録である場合は、セカンダリの一致パターンを利用してフェールオーバー機能をアプリケーションに提供することができなくなりました。プライマリ パターンがコール ルーティング テーブルに必ず存在するため、セカンダリ パターンに一致するかどうかは検索されません。


パターンにおける + 記号のサポート

Unified CM 内のすべてのパターン(ルート パターン、トランスレーション パターン、ディレクトリ番号など)では、+ 記号を使用できます。+ を文字どおりの意味で使用するには、+ の前にエスケープ文字 \ を入力することで、先行文字の 1 つ以上のインスタンスを意味する正規表現演算子の + と区別します。次に、例を示します。

\+14085264000 は +14085264000 を意味します。

2+ は 2、22、222 などを意味します。

Directory URI

Unified CM に登録されているすべてのエンドポイントは、1 つ以上の数字(先頭に + が付く場合もある)を含むディレクトリ番号でプロビジョニングされます。Cisco Unified CM 9.0 以降、各ディレクトリ番号に最大 5 個の Directory URI を関連付けることができます。この関連付けは、Directory URI をディレクトリ番号に明示的に関連付けることで作成できます。Directory URI がエンド ユーザに設定されている場合、そのエンドユーザにプライマリ内線番号が定義されるとすぐに、この Directory URI が自動的にそのエンドユーザのプライマリ内線番号と関連付けられます。自動的に関連付けられた Directory URI はパーティション Directory URI に作成されますが、手動設定された Directory URI はどのパーティションに置くこともできます。

正確には、ディレクトリ番号に関連付けられた Directory URI の 1 つが、そのディレクトリ番号のプライマリ Directory URI としてマークされる必要があります。ユーザ Directory URI がそのユーザのプライマリ内線番号に自動的に関連付けられる場合、その Directory URI は自動的にそのディレクトリ番号のプライマリ Directory URI にもなります。自動的に関連付けられた Directory URI がない場合、設定された Directory URI の 1 つがプライマリ Directory URI として選択される必要があります。プライマリ Directory URI の目的は、この Directory URI がそれぞれのディレクトリ番号から発信されたコールについて、発信 ID Directory URI として使用されることです。

Directory URI をどのディレクトリ番号とも関連付けすることが可能なため、関連付けられた Directory URI をダイヤルすることで、発信者はどのディレクトリ番号にも到達できます。着信側ディレクトリ番号は、任意のプロトコルを使用して Unified CM に登録された任意のデバイスになります。同様に、Unified CM は、Directory URI が発信側ディレクトリ番号に関連付けられている限り、どのディレクトリ番号からのコールにも Directory URI 発信者 ID を提供できます。

Unified CM の外部ルート

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

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

 

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

「ルート パターン」

「ルート リスト」

「ルート グループ」

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

ルート パターン

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

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

@ ワイルドカード

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

その他の国別番号計画を受け入れるように Unified CM を設定できます。この作業が完了すると、[Route Pattern] 設定ページの [Numbering Plan] フィールドで選択した値に応じて、同じ Unified CM クラスタ内で、複数の番号計画に対して @ ワイルドカードを使用できるようになります。詳細については、次の 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 文字にできます。

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

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

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

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

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

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

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

重複送信と重複受信

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

重複送信とは、エンド ユーザがダイヤルする番号を Unified CM で収集しながら、番号がダイヤルされると同時に PSTN に渡すことを意味します。重複送信を可能にするには、[Route Pattern] 設定ページの [Allow Overlap Sending] チェックボックスをオンにします。以前の Unified CM リリースで重複送信を使用可能にするには、SendingCompleteIndicator サービス パラメータを False に設定します。ルート パターンには、PSTN アクセス コード(たとえば、北米では 9、欧州諸国の多くでは 0)を含めるだけです。

重複受信とは、ダイヤルされる番号を PRI PSTN ゲートウェイから Unified CM で 1 つずつ受信し、ストリングのダイヤルが完了するまで待機し、その後でコールを内部宛先にルーティングすることを意味します。重複受信を可能にするには、OverlapReceivingFlagForPRI サービス パラメータを True に設定します。以前の Unified CM リリースでは、パラメータ名は OverlapReceivingForPriFlag です。

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

コールで最終的に利用するルート グループに関係なく、ルート パターンで設定する番号操作は、発呼側番号および着信側番号に影響を与えます。ルート リスト ビューにあるそのメンバーのルート グループに設定される番号操作が影響するのは、ルートに対してだけです。つまり、コールの発信に使用するルート グループに設定されている変換のみが実行されます。

ルート リスト ビューにあるそのルート グループの番号操作は、ルート パターンに設定される番号操作よりも優先されます。

ルート パターンやルート リストに設定される番号変換による発呼側番号および着信側番号は、選択したルート グループに含まれるデバイスに設定されているトランスフォーメーション パターンで処理されます。

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

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

発呼回線 ID

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

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

緊急優先(Urgent Priority)

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

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

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

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

コールの分類(Call Classification)

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

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

強制承認コード(FAC)

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

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

コール詳細レコード(CDR)に表示されるのは、承認名のみです。承認コードは CDR には表示されません。

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

クライアント識別コード(CMC)

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

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

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

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

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

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

SIP ルート パターン

SIP ルート パターンは、Unified CM で設定され、SIP URI のホスト部分(右側)に基づいて外部エンティティへのコールをルーティングまたはブロックします。SIP ルート パターンは、SIP トランクまたは 1 つ以上のルート グループに続いて最後に SIP トランクを参照するルート リストを直接ポイントすること(Unified CM 9.0 以降)ができます。いっそうの柔軟性のために、フル SIP ルート パターン、ルート リスト、ルート グループ コンストラクトの使用を推奨します。

SIP URI のホスト部分に一致する SIP ルート パターンは、ドメイン名または IP アドレス(両方とも SIP URI の右側にある可能性がある)と一致する場合があります。複数のドメインに一致するドメイン名の SIP ルート パターンでワイルド カードを使用できます(たとえば、*.cisco.com and ccm[1-4].uc.cisco.com)。IP アドレスの SIP ルート パターンでは、サブネット表記を使用できます(たとえば、192.168.10.0/24)。

ルート リスト

ルート リストは、発信コールに使用できるパス(ルート グループ)が優先順位順に並べられたリストです。ルート リストの標準的な用途は、リモートの宛先に 2 つのパスを指定することです。この場合、第一選択のパスは、IP WAN を介したパスであり、第二選択のパスは、PSTN ゲートウェイを介したパスです。

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

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

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

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

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

ルート パターンまたはルート グループ内で複数の番号操作を実行すると、変換が実行される順序が、コールに使用される、変換結果の発呼側番号および着信側番号に影響を与える可能性があります。Unified CM は、次に示す主要なタイプの番号操作を表示されている順に実行します。

1. 番号を破棄する

2. 発着信側変換

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

4. 発着信側トランスフォーメーション パターン

ルート グループ

ルート グループは、一般にゲートキーパーまたはリモート Unified CM クラスタとのゲートウェイ(MGCP、SIP、または H.323)、H.323 トランク、または Cisco Unified Border Element である特定のデバイスを制御し、それを指定します。Unified CM は、割り当てられている分配アルゴリズムに従ってコールをデバイスに送信します。Unified CM では、トップダウン アルゴリズムと循環アルゴリズムをサポートしています。

発信側および着信側トランスフォーメーション パターン

発信側トランスフォーメーション パターンを使用すると、発呼側番号のグローバル形式を、ゲートウェイ、トランクなどのルート グループ デバイスに接続されているオフクラスタ ネットワークで必要となるローカル形式に適応させることができます。

着信側トランスフォーメーション パターンを使用すると、着信側番号のグローバル形式を、ゲートウェイ、トランクなどのルート グループ デバイスに接続されているオフクラスタ ネットワークで必要となるローカル形式に適応させることができます。


) 着信側トランスフォーメーション パターンは、電話機に影響を与えません。また、デバイス プールの着信側トランスフォーメーション パターン CSS も、そのパターンが割り当てられている電話機に影響を与えません。


両方のトランスフォーメーション パターン タイプは、一致する発呼側番号または着信側番号の数値表現で構成されます。使用される構文は、ルート パターン、トランスフォーメーション パターン、ディレクトリ番号などのその他パターンの構文と同じです (図 9-38 を参照)。

変換演算子には、数字破棄命令(ドット前の番号など)、発信側トランスフォーメーション マスク、プレフィックス番号が含まれます。この演算子によって、発信側電話番号表示(Default、Allowed、または Restricted)が制御されます。発信側トランスフォーメーション パターンを設定することで、発信側の外部電話番号マスクを発呼側番号として使用できます。

パーティションおよびコーリング サーチ スペースによって、どの発信側トランスフォーメーション パターンをどのゲートウェイまたはトランクに適用するかどうかが制御されます。ゲートウェイまたはトランクでは、関連するデバイス プールの発信側変換 CSS またはデバイス固有の発信側変換 CSS を優先順位の低い順に使用できます。同じメカニズムを使用して、着信側トランスフォーメーション パターンの適用を制御します。

[Call Routing Information] > [Outbound Calls] の [Gateway Configuration] ページで設定された発信側および着信側トランスフォーメーション パターンは、ゲートウェイに送信される発呼側番号または着信側番号と、発信側または着信側の番号タイプおよび番号計画に影響します。[Incoming Calling Party Settings] で適用される発信側トランスフォーメーション パターンは、ゲートウェイから送信されるコールに適用されます。

図 9-38 発信側および着信側トランスフォーメーション パターン

 

図 9-38 は、発信側および着信側トランスフォーメーション パターンを、さまざまな PSTN で PSTN に接続しているゲートウェイの異なるグループに適用する方法を示しています。

北米番号計画(NANP)では、カナダの Ottawa(空港コード YOW)にあるゲートウェイは、パーティション NANP_calling_xforms が含まれている、発信側変換 CSS NANP_CgPTP に割り当てられます。発呼側番号が +1 で始まる(つまり、NANP 内から発信される)コールは、パーティション NANP_calling_xforms 内で設定されている両方のパターンに一致します。best-match ロジックの後、最初のパターンが選択され、発呼側番号から + 記号と NANP 国コード 1 が削除されます。残りの発呼側番号部分は PSTN に送信される発呼側番号として使用され、番号タイプは National に設定されます。

たとえば、+1 613 555 1234 からのコールを YOW ゲートウェイに送信した場合、その発呼側番号は 613 555 1234 に変換され、番号タイプは National に設定されます。

同じ発信側からのコールをフランスにあるゲートウェイに送信した場合には、一連の異なる発信側トランスフォーメーション パターンが適用されます。たとえば、+1 613 555 1234 からのコールをフランスの Nice(空港コード NCE)にあるゲートウェイに送信した場合、パーティション France_calling_xforms に含まれている発信側トランスフォーメーション パターンが適用されます。この場合、発呼側番号は 001 613 555 1234 に変換され、番号タイプは International に設定されます。


) コールをゲートウェイに送信すると、発呼側番号変換が無効になることがあります。多くのサービス プロバイダーでは、現地のサービス契約や規制で定められているように、特定の範囲外で発呼側番号を使用することを許可していません。


同じプロセスは、着信側番号トランスフォーメーション パターンにも適用されます。Ottawa ゲートウェイの場合、割り当てられた受信側変換 CSS は YOW_CdPTP です。これは、パーティション NANP_Called_xforms および YOW_Called_xforms に含まれています。番号計画エリア 613 内の宛先番号に発信されるコールは、これらの 2 つのパーティションに含まれているすべてのパターンに一致します。ただし、ベストマッチ プロセスによってパターン \+1.613[2-9]XXXXXX が選択されます。

たとえば、Ottawa ゲートウェイ経由で +1 613 555 9999 にコールを発信すると、着信側番号は 516 555 9999 に変換され、番号タイプは Subscriber に設定されます。

着信側の設定(ゲートウェイ別)

個々のゲートウェイには、優先順位に従ってデバイス プール レベルまたはサービス パラメータ レベルで着信側の設定を行うことができます。各番号タイプ(Subscriber、National、International、または Unknown)には、Unified CM で適切なプレフィックス番号を設定できます。 さらに、番号を削除したり、着信側番号として指定した番号にプレフィックス番号を付けたりできます。表記形式は PP:SS です。PP はプレフィックスとして付加される番号を表し、SS は削除される桁数を表します。最初に番号削除操作が着信側の番号で実行され、次にその結果の番号にプレフィックス番号が付加されます。たとえば、プレフィックス番号フィールドを +33:1 と設定し、着信側の番号が 01 58 40 58 58 である場合、+33 1 58 40 58 58 となります。

Cisco Unified CM 7.1 では、発信側トランスフォーメーション パターンをコールに適用するために使用するコーリング サーチ スペースを各番号タイプに設定できます。コーリング サーチ スペースには、発信側トランスフォーメーション パターンだけが存在するパーティションが保持される必要があります。これによって、厳密に番号タイプに基づくのではなく、発呼側番号の構造に基づいた変更を発呼側番号に適用できます。発信側トランスフォーメーション パターンでは、正規表現を使用して発呼側番号が照合されます。複数の一致項目から選択するには、best-match プロセスが使用され、選択されたパターンの発信側変換がコールに適用されます。

ルート グループ デバイス

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

メディア ゲートウェイ コントロール プロトコル(MGCP)ゲートウェイ

SIP ゲートウェイ

H.323 ゲートウェイ

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

クラスタ間トランク、非ゲートキーパー制御:別の Unified CM クラスタとの直接トランク

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

SIP トランク:別の Unified CM クラスタとのトランク、Cisco Unified Border Element、セッション ボーダー コントローラ、または SIP プロキシ


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


ローカル ルート グループ

デバイス プールは、ローカル ルート グループに関連付けることができます。ローカル ルート グループを使用したルート パターンには、固有の特性があります。つまり、コールの発信元デバイスに基づいて出口ゲートウェイを動的に選択できます。それに対し、スタティック ルート グループを使用したルート パターンによってルーティングされるコールでは、コールの発信元デバイスに関係なく、コールが同じゲートウェイにルーティングされます。

例 9-2 ローカル ルート グループと非ローカル ルート グループの比較

図 9-39 では、9.1[2-9]XX[2-9]XXXXXX と定義されたルート パターンは、San Francisco ゲートウェイを含む非ローカル ルート グループを参照するルート リストを指しています。このルート パターンが Dallas、San Francisco、および New York の電話機のコーリング サーチ スペースに含まれているパーティションにある場合、それらの 3 つの都市にあるデバイスからの国内コールの出口は San Francisco の PSTN となります。

図 9-39 非ローカル ルート グループの動作

 

一方、図 9-40 に示すように、同じルート パターンを変更して、標準ローカル ルート グループを含むルート リストを指すようにした場合、Dallas サイトから発信されるコールの出口は Dallas ゲートウェイを経由した公衆網となり、New York サイトから発信されるコールの出口は New York ゲートウェイを経由した公衆網となり、San Francisco サイトから発信されるコールの出口は San Francisco ゲートウェイを経由した公衆網となります。

図 9-40 ローカル ルート グループの動作

 

デバイス モビリティ機能を使用すると、ローミングしている現在のサブネットに基づいて、デバイス プールをエンドポイントに割り当てることができます。これにより、電話機の現在のサイトに基づいた、ローカル ルート グループの割り当てが可能になります。

例 9-3 デバイス モビリティ

電話機を San Francisco サイトから New York サイトに移動するとします。電話機の新しい IP アドレス(New York サイトに関連付けられた IP サブネット部分)に基づいて、New York のデバイス プールがその電話機に割り当てられます。ローミング電話機によって発信される次のコールは、標準ローカル ルート グループを含むルート リストを使用したルートと一致し、New York ゲートウェイを経由してルーティングされます。

ローカル ルート グループが転送コール シナリオで使用されている場合(たとえば、電話機 A から電話機 B にコールし、B が PSTN 内の宛先に転送される場合)、電話機 B のコール転送コーリング サーチ スペースのルート パターンによって、電話機 B から転送されるコールのサービス クラスが特定されます。一方、デフォルトでは電話機 A のデバイス プールに関連付けられたローカル ルート グループは、電話機 B のコール転送コーリング サーチ スペースを使用して見つかったルート パターンで選択されているルート リスト内の標準ローカル ルート グループにヒットする場合、出力ゲートウェイの特定に使用されます。その結果、一般的には電話機 A に対してローカルなゲートウェイが転送コールに使用されます。これにより、最初の発信者(電話機 A)の発信者 ID を PSTN に送信でき、この発信者 ID はプロバイダーによってスクリーニングされません。Unified CM 9.0 以降には、転送コールのローカル ルート グループ選択ポリシーの設定を可能にするサービス パラメータがあります。サービス パラメータは次のように設定できます。

Calling Party's Local Route Group :下位互換性のあるデフォルト。最初の発信者のデバイス プールに関連付けられたローカル ルート グループが選択されます(上の例では電話機 A)。

Original Called Party :着信側電話機のデバイス プールに関連付けられたローカル ルート グループが選択されます(上の例では電話機 B)。

Last Redirecting Party :PSTN にコールを転送している電話機のデバイス プールに関連付けられたローカル ルート グループが選択されます(上の例では電話機 B)。これらの最後の 2 通りの方法は、PSTN に最後に転送される前に、コールが複数のホップを介して転送される場合にのみ異なります。

PSTN へのローカル フェールオーバーを使用した中央ゲートウェイ

中央ゲートウェイが設定されているシステムの場合、ローカル ルート グループによって、PSTN へのローカル フェールオーバーが簡素化されます。発信側サイトでゲートウェイへのローカル フェールオーバーが許可されているときに、単一のルート リストを使用することで、複数サイトの PSTN コールをルーティングできます。

例 9-4 中央ゲートウェイとローカル フェールオーバー

ある会社が、Chicago にあるトランクのグループに有利な PSTN 相互接続レートをネゴシエートするとします。ルート リストに、1 番めの項目として Chicago にあるゲートウェイを含むルート グループが含まれ、2 番めの項目として標準ローカル ルート グループが含まれている場合、処理されるコールは最初に Chicago にある低コストの推奨ゲートウェイに送信されます。Chicago ゲートウェイが使用可能でない、フリー ポートがない、あるいは発信側電話機と Chicago ゲートウェイ間で使用できる帯域幅が十分でない場合は、発信側電話機のデバイス プール設定でローカル ルート グループによって決定されている、2 番めの項目を使用して、発信側電話機と同じ場所にあるゲートウェイを経由したコールのルーティングが試行されます (図 9-41 を参照)。

図 9-41 PSTN へのローカル フェールオーバーを使用した中央ゲートウェイ

 

Unified CM での SIP 要求のルーティング

SIP トランクまたは SIP エンドポイントから受信した SIP 要求のルーティングは、特定のルールに従い、ローカルとクラスタ間の両方のルーティング要件が満たされます。図 9-42 に、Unified CM によるルーティング決定のフロー チャートを示します。最初の手順は、URI の左側(ユーザ部分)が、ディレクトリ番号と Directory URI のどちらかを確認することです。

図 9-42 SIP 要求のコール ルーティング ロジック

 

数値 URI と Directory URI

SIP 要求に user=phone タグがある場合、SIP URI は常に数値 SIP URI として解釈され、Unified CM は SIP URI のユーザ部分をディレクトリ番号と見なします。user=phone が存在しない場合、発信側デバイス(エンドポイントまたはトランク)の SIP プロファイルのダイヤル ストリング解釈の設定に基づいて決定されます。この設定は、Unified CM が数値 SIP URI として受け入れる文字セット(0 ~ 9、*、#、+ およびオプションとして A ~ D)を定義するか、または Directory URI としての解釈を強制します。

Unified CM 9.0 以前のリリースでは、すべての SIP URI が常に数値 SIP URI として処理されます。

Directory URI のルーティング

SIP URI を非数値として識別した後の手順は、発信側デバイスのコーリング サーチ スペースに基づいて SIP 要求をルーティングすることです。Unified CM は、発信側デバイスのコーリング サーチ スペースによって指定されたパーティションに設定されたすべての Directory URI に対して SIP URI の完全一致を検索します。一致が見つかった場合、コールは一致したローカル Directory URI に関連付けられたディレクトリ番号に伝送されます。

一致するローカル Directory URI が存在しない場合、Unified CM はインポートされた Directory URI カタログまたは ILS を介してリモート システムから学習した URI カタログで、再び完全一致によって SIP URI を探します。一致が見つかった場合、SIP 要求は、見つかった Directory URI に関連付けられた SIP ルート文字列と設定済み SIP ルート パターンの一致によってルーティングされます。(図 9-43を参照)。

SIP URI がローカル Directory URI で一致せず、どの Directory URI カタログ内の Directory URI ともマッチしない場合、Unified CM は SIP URI の右側のみと設定済み SIP ルート パターンとの一致に基づいて SIP 要求をルーティングします。この最終手段のルーティングは、ローカルや ILS を介して接続される他の呼制御で不明なすべての SIP URI にデフォルト ルートを作成するのに使用できます。

図 9-43 Directory URI のルーティング例

 

図 9-43 に、ダイヤルされた Directory URI が Unified CM によってルーティングされる例を示します。この例では、下の Unified CM クラスタがローカル Directory URI「carol@cisco.com」をアドバタイズします。この Unified CM クラスタのすべてのローカル Directory URI は、SIP ルートストリング「fra.cisco.com」のもとにアドバタイズされます。ILS を介したこの情報交換の一部として、最上部の Unified CM クラスタは自身のローカル Directory URI カタログに「carol@cisco.com」から SIP ルートストリング「fra.cisco.com」への関連付けを読み込みました。最上部のクラスタに登録された電話機から Directory URI「carol@cisco.com」コールがなされた場合、Directory URI「carol@cisco.com」のローカル ルックアップは失敗します。「carol@cisco.com」はローカル Directory URI ではないからです。ルーティング プロセスの次のステップは、ILS が学習したテーブルで Directory URI「carol@cisco.com」を検索することです。この検索では、下部のクラスタから学習した情報を見つけることができ、最上部の発信元クラスタは学習した SIP ルーティング「fra.cisco.com」を使用し、SIP ルートストリング「fra.cisco.com」と設定済みルート パターンのマッチングでルートを探します。SIP ルート パターン「fra.cisco.com」が設定され、ルート リストをポイントします。ルートリストは最終的にはターゲット Unified CM クラスタをポイントする SIP トランクに到達します。発信元 Unified CM クラスタは、こうして宛先 Unified CM クラスタにコールをルーティングします。送信された SIP 要求の宛先は「carol@cisco.com」になります。宛先クラスタでは、図 9-42 に示したのと同じルーティング ロジックが、「carol@cisco.com」を宛先クラスタ上のすべてのローカル Directory URI とマッチングし、完全一致が見つかってターゲット デバイスが鳴ります。

数値 URI のルーティング

SIP URI が数値 URI と見なされるのは、要求に user=phone タグが含まれている場合、または発信側デバイスの SIP プロファイルのダイヤル ストリング解釈設定に基づきます。コールは図 9-44 のフローチャートに従って処理されます。リリース 9.0 以前の Unified CM では、これが SIP 要求の標準ルーティング手順です。

図 9-44 数値 SIP 要求のコール ルーティング ロジック

 

最初のステップでは、SIP URI の右側が Unified CM クラスタのメンバーであるサーバの IP アドレスであるか、または Unified CM エンタープライズ パラメータに設定されているクラスタの完全修飾ドメイン名に一致するかを確認します。この場合、URI の左側は市内電話番号と見なされ、発信側デバイスのコーリング サーチ スペースを使用して番号としてルーティングされます。

次のステップでは、SIP URI の右側が、Unified CM エンタープライズ パラメータに設定されている組織のトップレベルのドメインに一致するかどうかを確認します。一致する場合、Unified CM は発信側デバイスのコーリング サーチ スペースを使用してコールを再度ルーティングしようとします。一致するものが見つからない場合、ルーティングはフォールバックし、設定されている SIP ルート パターンに SIP URI の右側を照合することによってコールがルーティングされます。

Unified CM クラスタに、IP アドレスが 192.168.10.10、192.168.10.11、192.168.20.10、および 192.168.20.11 のメンバー、ucm1.cisco.com として設定されているクラスタの完全修飾ドメイン名、および cisco.com として設定されている組織のトップレベルのドメインが含まれていると仮定すると、次の SIP URI はすべて市内電話番号 1234 にルーティングされます。

1234@192.168.10.10

1234@192.168.10.11

1234@192.168.20.10

1234@192.168.20.11

1234@ucm1.cisco.com

1234@cisco.com

市内電話番号 1234 が存在しないと仮定すると、最初の 5 つのコールはすぐに失敗し、Unified CM は、設定されている SIP ルート パターンに cisco.com を照合することによって、6 番めのコールをルーティングしようとします。

Unified CM におけるコール特権

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

「パーティション」

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

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

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

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

 

パーティション

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

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

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

 


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


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

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

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

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

図 9-47 IP Phone の回線とデバイスのコーリング サーチ スペース(CCS)の連結

 


) デバイス モビリティを使用しない場合、デバイスのコーリング サーチ スペースは静的となり、デバイスをネットワークの別の場所に移動しても同じままです。デバイス モビリティを有効にした場合、電話機の IP アドレスによって決定されている、ネットワークで電話機が物理的に配置されている場所に基づいて、デバイスのコーリング サーチ スペースを動的に決定できます。詳細については、「デバイス モビリティ」を参照してください。


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

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

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

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

http://www.cisco.com

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


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



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


トランスフォーメーション パターンの特別な考慮事項

発信側および着信側トランスフォーメーション パターンは、パーティションにも配置されます。それらのパーティションは、コーリング サーチ スペース(CSS)に含まれますが、コール特権を制御するためのものではありません。トランスフォーメーション パターンのパーティションの役割は、どの変換をどのゲートウェイ、トランク、または電話機に適用するかを選択することです。発信側トランスフォーメーション パターン CSS に含まれるパーティションには、発信側トランスフォーメーション パターンのみが含まれていなければなりません。同様に、着信側トランスフォーメーション パターン CSS に含まれるパーティションには、着信側トランスフォーメーション パターンのみが含まれていなければなりません。

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


) この機能が電話機によってアクティブになっている場合、Call Forward All 動作は、宛先番号が個々のユーザによって入力されるその他の自動転送動作とは異なります。


自動転送コーリング サーチ スペースを有効にする方法を決定できます。Calling Search Space Activation Policy(コーリング サーチ スペースのアクティベーション ポリシー)によって指定されている、選択可能なオプションは次の 3 つです。

システム デフォルトの使用(Use System Default)

Calling Search Space Activation Policy を Use System Default に設定した場合、クラスタ全体のサービス パラメータである CFA CSS Activation Policy によって、使用される Forward All コーリング サーチ スペースが決定されます。CFA CSS Activation Policy サービス パラメータを With Configured CSS または With Activating Device/Line CSS に設定できます(下記を参照してください)。デフォルトでは、CFA CSS Activation Policy サービス パラメータは With Configured CSS に設定されています。

With Configured CSS

With Configured CSS オプションを選択した場合、Directory Number Configuration ウィンドウで明示的に設定されている Forward All コーリング サーチ スペースと Forward All のセカンダリ コーリング サーチ スペースによって、不在転送のアクティブ化と自動転送が制御されます。Forward All コーリング サーチ スペースを None に設定した場合、Forward All に対して CSS は設定されません。そのため、パーティションおよびディレクトリ番号に対する不在転送のアクティブ化の試行は失敗します。不在転送のアクティブ化中に、Forward All コーリング サーチ スペースおよび Forward All のセカンダリ コーリング サーチ スペースの変更は発生しません。

With Activating Device/Line CSS

Forward All コーリング サーチ スペースを明示的に設定せずに、ディレクトリ番号のコーリング サーチ スペースとデバイスのコーリング サーチ スペースの組み合わせを使用する場合には、Calling Search Space Activation Policy に対して With Activating Device/Line CSS を選択します。Forward All が電話機によってアクティブになっている場合にこのオプションを選択すると、Forward All コーリング サーチ スペースと Forward All のセカンダリ コーリング サーチ スペースに、ディレクトリ番号のコーリング サーチ スペースとアクティブ化デバイスのデバイス コーリング サーチ スペースが自動的に入力されます。Unified CM Administration から宛先への Forward All を設定した場合、Forward All コーリング サーチ スペースとセカンダリ コーリング サーチ スペースは自動的にはデータが格納されず、明示的に設定しなければなりません。その 2 つのコーリング サーチ スペースが連結され、連結されたコーリング サーチ スペースを使用することで、Call Forward All 宛先として入力されている番号を検証します。詳細については、「回線/デバイス アプローチによる Unified CM のサービス クラスの構築」を参照してください。

不在転送が電話機によってアクティブになっているときに、Forward All コーリング サーチ スペースを None に設定した場合にこの設定(Calling Search Space Activation Policy を With Activating Device/Line に設定)を使用すると、ディレクトリ番号のコーリング サーチ スペースとアクティブになっているデバイス コーリング サーチ スペースを使用することで、不在転送の試行を検証します。


) 通常、Call Forward All 設定では、2 つの要件を満たす必要があります。その 2 つの要件とは、デバイスでコールの転送が許可されている宛先を制御することと、さまざまな発信地点から発信するコールが Call Forward All 宛先に転送されるときに最適なコール ルーティングを実現することです。両方の要件を満たすためには、回線/デバイス ダイヤル プラン アプローチによる宛先の制御を可能にする With Configured CSS アクティベーション ポリシーを使用することを推奨します。Call Forward All CSS を使用して、ブロック パターンによる制限セットを実装します。通常のサービス クラスを Call Forward All に使用する場合、Call Forward All CSS は、回線で設定されているのと同じコーリング サーチ スペースに設定できます。その後、標準ローカル ルート グループにコールをルーティングするように、Secondary Calling Search Space for Call Forward All を設定する必要があります。デバイスのデバイス プールで設定されている、発信側(転送)デバイスのローカル ルート グループに基づいて、コールのルーティングに使用される実際のルート グループがコール時に決定されます。


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

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


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


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

その他の自動転送タイプ

さまざまな自動転送タイプ(Forward Busy、Forward No Answer、Forward No Coverage、Forward on CTI Failure、Forward Unregistered)に対して設定されているコーリング サーチ スペースは、他のどのコーリング サーチ スペースとも連結されないスタンドアロン値です。

Call Forward 設定(Forward All を除く)は、内部または外部のコール タイプ別に設定できます。たとえば、電話機で外部発信者のボイスメールに Call Forward No Answer を設定しても、発信者がネットワーク上の別の IP Phone から発信している社員である場合には、ボイスメールを携帯電話番号に転送できます。これを可能にするには、内線と外線の Call Forward 設定に対して、異なる設定を使用します。

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

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

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

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

Call Forward Unregistered(CFUR)機能は、一時的に登録から外されている宛先の電話機に発信されたコールを再ルーティングする手段です。CFUR の設定は、主に次の 2 つの要素で構成されます。

宛先の選択

DN が登録から外されているときに、コールを次のいずれかの宛先に再ルーティングできます。

ボイスメール

ボイスメールのチェックボックスをオンにし、CFUR コーリング サーチ スペースを設定して、ボイスメールのパイロット番号を含めることで、コールをボイスメールに送信できます。

PSTN を経由した電話機への到達に使用するディレクトリ番号

このアプローチが適切となるのは、WAN リンクがダウンするサイト内に電話機がある場合です。そのサイトに Survivable Remote Site Telephony(SRST)が装備されている場合は、電話機(および同じ場所にある PSTN ゲートウェイ)が同じ場所にある SRST ルータに再登録されます。その後、電話機は、その PSTN DID 番号に発信されたコールの受信を行うことができます。

この場合、適切な CFUR 宛先は、対応する元の宛先 DN の PSTN DID 番号です。宛先フィールドにこの PSTN DID を設定します。+ 記号を含む E.164 形式で設定することを推奨します(たとえば、+1 415 555 1234)。これによって、同じオフネット アクセス コードと PSTN プレフィックスを登録から外された電話機として使用するかどうかに関係なく、発信側電話機のローカル ルート グループによる CFUR 宛先の処理が可能になります。

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

Unified CM では、着信側 DN の CFUR コーリング サーチ スペースを使用することで、設定済みの宛先番号へのコールのルーティングを試行します。CFUR コーリング サーチ スペースは、対象の電話機に設定され、登録から外されている電話機に発信するすべてのデバイスで使用されます。つまり、すべての発信側デバイスでは、ルート パターン、ルート リスト、ルート グループの同じ組み合わせを使用して、コールを発信します。標準ローカル ルート グループを参照するルート リストを指すパターンを使用して、コールを CFUR 宛先にルーティングするために、CFUR コーリング サーチ スペースを設定することを推奨します。これによって、発信側デバイスに基づいて PSTN への出口ゲートウェイが選択されるようになります。

電話機が単にネットワークから切断されている場合と同様に、電話機が登録から外されている一方で、電話機の DID 番号に関連付けられているゲートウェイが依然として Unified CM の制御下にある場合に、Call Forward Unregistered 機能を使用すると、テレフォニー ルーティング ループが発生することがあります。このような場合、電話機への初期化コールによって、電話機の DID への最初のコールが PSTN 経由で試行されます。次に、同じ電話機の DN に到達するために、その結果の着信 PSTN コールによって、別の CFUR 試行がトリガーされ、さらに、PSTN を経由して PSTN の中央ゲートウェイから別の CFUR コールがトリガーされます。システム リソースが使い果たされるまで、このサイクルが繰り返されます。

MaximumForwardUnRegisteredHopsToDn サービス パラメータによって、DN に対して同時に許可される CFUR コールの最大数が制御されます。デフォルト値 0 は、カウンタが無効であることを意味します。PSTN 経由で CFUR を再ルーティングするように DN を設定した場合には、ループを防止する必要があります。このサービス パラメータを値 1 に設定すると、CFUR のメカニズムで 1 つのコールを発信するとすぐに、CFUR 試行が停止されます。CFUR が設定されている場合には、この設定によって、1 つのコールだけをボイスメールに転送することも可能です。このサービス パラメータを値 2 に設定すると、最大 2 人の同時発信者が、ボイスメールに対して CFUR 設定が設定されている DN のボイスメールに到達でき、CFUR 設定によって PSTN を経由してコールが送信される DN に対して、発生する可能性があるループを 2 つに制限できます。


) Call Forward Unregistered コールを DN に関連付けられている PSTN DID に送信するために、エクステンション モビリティの DN を設定しないでください。ログアウト状態になっている、エクステンション モビリティ プロファイルの DN は登録から外されていると見なされます。そのため、ログアウト状態の DN の PSTN DID 番号へのコールによって、ルーティング ループがトリガーされます。ログアウト状態になっている、エクステンション モビリティの DN へのコールがボイスメールに確実に送信されるように、対応する Call Forward Unregistered パラメータを設定してコールがボイスメールに送信されることを確認します。


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

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

トランスレーション パターンは、図 9-48 の例に示すように、さまざまな用途に使用できます。

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

 

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


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


Automated Alternate Routing(自動代替ルーティング)

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

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

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


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


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

「宛先 PSTN 番号の確立」

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

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

宛先 PSTN 番号の確立

コールを再ルーティングするには、PSTN などの代替ネットワーク経由でルーティングできる宛先番号を使用する必要があります。AAR では、ダイヤルされた番号を使用してコールのオンクラスタでの宛先を特定し、その番号を着信側の AAR 宛先マスクと結合します。AAR 宛先マスクが設定されていない場合には、その代わりに外部電話番号マスクが使用されます。ダイヤルされた番号と適切なマスクを結合することで、代替ネットワークによってルーティング可能な、完全修飾番号を生成する必要があります。

または、AAR 設定でボイスメールのチェックボックスをオンにすることで、コールをボイスメールのパイロット番号に転送できます。この選択では、発信者によってダイヤルされた元の番号を利用しませんが、ボイスメール プロファイル設定に従ってコールがルーティングされます。


) デフォルトでは、ディレクトリ番号設定によってコールの AAR レッグがコール履歴に保持されます。これによって、ボイス メッセージング システムへの転送で適切なボイスメールボックスが選択されます。「Remove this destination from the call forwarding history」を選択した場合には、コールの AAR レッグがコール履歴に保持されません。そのため、ボイスメールボックスが自動的に選択されなくなり、発信者に汎用ボイスメール グリーティングが提供されます。


AAR 宛先マスクを使用することで、外部電話番号マスクと無関係に、宛先の電話番号を決定できます。たとえば、会社の発信者 ID ポリシーに基づいて、電話機の外部電話番号マスクをオフィスの代表電話番号(415 555 1000 など)にする必要がある場合、AAR に電話機固有の PSTN 番号を提供するために、AAR 宛先マスクを +1 415 555 1234 に設定できます。

たとえば、San Francisco にある電話機 A(DN = 2345)から、New York にある電話機 B 上に設定されているオンネット DN(1234)にダイヤルするとします。ロケーションベースのコール アドミッション制御によってコールが拒否された場合、AAR は New York の電話機の AAR 宛先マスク(+1212555XXXX)を取得して使用し、PSTN 上でルーティング可能な番号(+12125551234)を導出します。

AAR 宛先マスクを設定して + 記号を含む完全修飾 E.164 番号を生成することが最善の方法となります。その理由は、この方法によって AAR 設定全体が大幅に簡素化されるためです。たとえば、Paris にある電話機は AAR 宛先マスク +33 1 58 04 58 58 で設定されます。この番号は完全修飾 E.164 番号であるため、発信側電話機がフランスやカナダにあるか、世界のどこにあるかに関係なく、発信側電話機の PSTN へのゲートウェイによって要求されるルーティング可能な PSTN 番号を導出するために、Cisco Unified Communications システムに必要なすべての情報がこの番号に含まれています。次の項では、このアプローチについて詳しく説明します。

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

AAR 宛先で + 記号を含む完全修飾 E.164 番号を生成する場合

これが最も単純なケースです。AAR 宛先には、ワイルドカードとして + が含まれています。+ は、各ゲートウェイで必要となる適切なアクセス コードに置き換えられます。適切なルート パターンにルーティングされるように宛先番号が準備されます。その後、適切な着信側トランスフォーメーション パターンによって宛先番号が PSTN への出口点で変換されます。

例 1: カナダの Ottawa にある電話機が Paris にある電話機に発信していますが、WAN の帯域幅が不足しているために AAR がトリガーされます。AAR 宛先は +33 1 58 04 58 58 です。発信側電話機の AAR コーリング サーチ スペースには、コールを標準ローカル ルート グループにルーティングするルート パターン \+! が含まれています。コールは、Ottawa にあるローカル ゲートウェイにルーティングされ、そこで、着信側トランスフォーメーション パターンによって + が適切な国際アクセス コード 011 に置き換えられます。その結果、011 33 1 58 04 58 58 にコールが発信されます。

例 2: フランスの Nice にある電話機が Paris にある電話機に発信していますが、WAN の帯域幅が不足しているために AAR がトリガーされます。AAR 宛先は +33 1 58 04 58 58 です。発信側電話機の AAR コーリング サーチ スペースには、コールを標準ローカル ルート グループにルーティングするルート パターン \+! が含まれています。コールは、Nice にあるローカル ゲートウェイにルーティングされ、そこで、着信側トランスフォーメーション パターンによって + 33 が適切な国内アクセス コード 0 に置き換えられます。その結果、01 58 04 58 58 にコールが発信されます。

AAR 宛先マスクで国コードを含む番号を生成する場合

宛先番号(国コードが含まれると前提)が元の支店のダイヤル プランによって正常にルーティングされるためには、プレフィックスが必要になる場合があります。また、発信地点が別のエリア コードまたは別の国に配置されている場合、ダイヤルされたストリングの一部として、国際ダイヤル アクセス コード(たとえば、00、011)などの他のプレフィックスが必要になる場合があります。

AAR を設定する場合は、DN を AAR グループ内に配置します。AAR グループのペアごとに、同じ AAR グループ内で発信または終端するコールのプレフィックス番号も含めて、その 2 グループ間のコールで DN に追加するプレフィックス番号を設定できます。

一般的な規則として、複数の DN が各国間で同じダイヤリング構造を共有している場合は、それらの DN を同じ AAR グループに配置します。たとえば、UK 国外にある UK ダイヤル番号のすべての電話機は、9 を PSTN アクセス コードとして使用し、その後に国際アクセス コードの 00 が続きます。フランスおよびベルギーにあるすべての電話機は、0 を PSTN アクセス コードとして使用し、その後に国際アクセス コードの 00 が続きます。NANP にあるすべての電話機は、9 を PSTN アクセス コードとして使用し、その後に国際アクセス コードの 011 が続きます。

これによって、AAR グループ設定は次のようになります。

AAR グループ
NANP
Cent_EU
UK
NANP

9

9011

9011

Cent_EU

000

000

000

UK

900

900

9

例 3: カナダの Ottawa にある電話機が Paris にある電話機に発信していますが、WAN の帯域幅が不足しているために AAR がトリガーされます。AAR 宛先は 33 1 58 04 58 58 です。発信側電話機の AAR グループは NANP であり、宛先番号の AAR グループは Cent-EU です。したがって、プレフィックス 9011 が付加されます。発信側電話機の AAR コーリング サーチ スペースには、コールを Ottawa のルート リストにルーティングして 9 を削除する、サイト固有のルート パターン 9011! が含まれています。コールは、Ottawa にあるローカル ゲートウェイにルーティングされます。その結果、011 33 1 58 04 58 58 にコールが発信されます。

例 4: ベルギーの Brussels にある電話機が Paris にある電話機に発信していますが、WAN の帯域幅が不足しているために AAR がトリガーされます。AAR 宛先は 33 1 58 04 58 58 です。発信側電話機および宛先番号の AAR グループは Cent-EU です。したがって、プレフィックス 000 が付加されます。発信側電話機の AAR コーリング サーチ スペースには、コールを Brussels のルート リストにルーティングして先行する 0 を削除する、サイト固有のルート パターン 000! が含まれています。コールは、Brussels にあるローカル ゲートウェイにルーティングされます。その結果、00 33 1 58 04 58 58 にコールが発信されます。

ボイスメールの考慮事項

AAR は、コールをボイスメールに転送できます。通常、オフネット アクセス コードなしでボイスメールのパイロット番号がダイヤルされます(ボイスメールのパイロット番号が 8 555 1000 などの完全修飾のオンネット番号である場合)。コールをボイスメールに送信するために AAR を設定すると、AAR グループ メカニズムによって、設定済みのアクセス コードも付加されます。この設定には、AAR グループを作成する必要があります。AAR グループは、必要な AAR 宛先がボイスメール(たとえば、vmail_aar_grp)となっているすべての DN によって使用されます。他の AAR グループの DN からコールを受信するときに、このボイスメールの AAR グループでプレフィックス番号を使用しないことを確認してください。

例: San Francisco サイトおよび New York サイトにある DN が、AAR グループ NANP で設定され、そのグループにある任意の 2 つの DN 間のコールに 9 が付加されるとします。San Francisco にある DN を設定して AAR コールをボイスメールに送信した場合(たとえば、8 555 1000)、985551000 にコールが発信されますが、そのコールは失敗します。その代わりに、San Francisco にある DN を AAR グループ vmail で設定します。次の表に示すように、AAR グループ NANP から AAR グループ vmail へのコールのプレフィックス番号は <none> です。これで、コールが正常に 85551000 に発信されます。

AAR グループ
NANP
Cent_EU
UK
vmail
NANP

9

9011

9011

<none>

Cent_EU

000

000

000

<none>

UK

900

900

9

<none>


) デバイス モビリティを使用しない場合、DN ドメインの AAR グループ設定は、デバイスがネットワークの別の場所に移動しても同じままです。デバイス モビリティを使用した場合、電話機の IP アドレスによって決定された、ネットワークで電話機が物理的に配置されている場所に基づき、ARR グループを動的に決定できます。詳細については、「デバイス モビリティ」を参照してください。


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

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

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

ローカル ルート グループを使用し、さらに完全修飾 E.164 アドレス(+ 記号を含む)を AAR 宛先マスクとして使用すると、AAR コーリング サーチ スペース設定を大幅に簡素化することできます。単一のパーティションで設定され、単一のルート パターン \+! が含まれ、さらに標準ローカル ルート グループを備えた単一のルート リストを指している単一のコーリング サーチ スペースを使用することで、クラスタ全体のすべてのサイトですべてのコールをルーティングできます。これは、適切なゲートウェイ固有の着信側トランスフォーメーション パターンを利用して、宛先番号のユニバーサル形式を、各サイトでコールが送信されるサービス プロバイダー ネットワークで必要となるローカル形式に適応させます。


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



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



) デバイス モビリティを設定した場合、電話機の IP アドレスによって決定されている、ネットワークで電話機が物理的に配置されている場所に基づいて、ARR コーリング サーチ スペースを動的に決定できます。詳細については、「デバイス モビリティ」を参照してください。


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

場合によっては、同じ AAR グループに属する電話機のサイト間でダイヤリングを使用できるように AAR ダイヤル ストリングをローカルに修正する必要があります。たとえば、フランスにある 2 つのサイトが、同じ国コード 33 を共有しているとします (図 9-49 を参照)。この場合は、0 00 33 1 58 04 58 58 としてダイヤルされた番号を 01 58 04 58 58 に変換する必要があります。この変換が必要となるのは、AAR 設定で着信側トランスフォーメーション パターンを利用しない場合だけです。

この変換を実行する最良の方法は、サイト固有のトランスレーション パターン 00033.[1-6]XXXXXXXX を設定することです(ドットの前の番号を削除して、先頭に 0 を付加します)。このトランスレーション パターンは、フランスのサイトの AAR コーリング サーチ スペースのメンバー パーティションにのみ配置します。ベルギーのサイトからは、この同じ宛先に 0 00 33 1 58 04 58 58 として到達する必要があります。

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

 


) AAR 機能は、宛先の電話が到達不能であることが検出されてもトリガーしません。したがって、WAN の障害によって AAR 機能がトリガーすることはありません。


この状況を十分に理解するために、London(英国)、Paris(フランス)、Nice(フランス)にサイトがある Unified CM クラスタの例を考えます。Paris の DID 範囲の E.164 アドレスは、+33145678XXX です。ただし、フランスの PSTN 内からコールする場合、これらの内線には、通常は 0145678XXX として到達します。London のオフィスにいる人物が Paris のオフィスに PSTN 経由でダイヤルする場合、そのストリングは 90033145678XXX です。一方で、Nice のオフィスにいる人物が Paris のオフィスに PSTN 経由でダイヤルする場合、そのストリングは 00145678XXX です。

単一の単純な ARR 設定を使用して上記の 3 つのケースを可能にするには、完全修飾 E.164 番号(+ 記号を含む)で AAR 宛先マスクを設定することが最善の方法となります。これによって、発信側電話機ごとに解釈できる宛先番号が作成されます。

デバイス モビリティ

デバイス モビリティには、IP ネットワーク内にあるデバイスのモビリティが向上するように設計された機能が備わっています (たとえば、本来 San Francisco で使用するように設定されている電話機を物理的に New York に移動させます)。デバイスは依然として同じ Unified CM クラスタに登録されますが、電話機が置かれている新しいサイトに基づいて、デバイスの一部の動作が調整されます。これらの変更は、電話機のある IP サブネットによってトリガーされます。

ローミングするとき、電話機はデバイスの現在のサブネットに関連付けられているデバイス プールに関連付けられているパラメータを継承します。ダイヤル プランから見て、次の 5 つの主要な設定パラメータの機能は、電話機の物理的な場所により変更できます。変更するこれらのパラメータについて、デバイスはホーム ロケーションの外部をローミングしているが、ホーム デバイスのモビリティ グループ内にいると見なされます。

ローカル ルート グループ

ローミング デバイス プールのローカル ルート グループが使用されます。たとえば、San Francisco から New York にデバイスがローミングする場合、パターンが標準ローカル ルート グループを呼び出すルート リストを指している場合は常に、PSTN へのコールのルーティングに New York デバイス プールのローカル ルート グループが使用されます。

発信側変換 CSS

ローミング デバイス プールの発信側変換 CSS が使用されます。これにより、電話機は発信側電話番号表示モード(訪問した場所にある電話機の慣習的表示モード)を継承できます。

デバイス コーリング サーチ スペース

デバイス設定ページで設定されているデバイス コーリング サーチ スペースではなく、ローミング デバイス プールのデバイス モビリティ コーリング サーチ スペースが使用されます。たとえば、デバイスが San Francisco から New York にローミングしているとき、New York デバイス プールのデバイス モビリティ コーリング サーチ スペースが、ローミング電話機のデバイス コーリング サーチ スペースとして使用されます。サービス クラスに対して回線/デバイス アプローチを使用している場合、このアプローチは PSTN コールが取るパスを確立し、ローカルな New York ゲートウェイにルーティングします。

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

デバイス設定ページで設定されている AAR コーリング サーチ スペースではなく、ローミング デバイス プールの AAR モビリティ コーリング サーチ スペースが使用されます。たとえば、デバイスが San Francisco から New York にローミングしているとき、New York デバイス プールの AAR コーリング サーチ スペースが、ローミング電話機の AAR コーリング サーチ スペースとして使用されます。このコーリング サーチ スペースは発信 AAR PSTN コールが取るパスを確立し、ローカルな New York ゲートウェイにルーティングします。

DN の AAR グループ

着信 AAR コールの場合、DN のホスト電話機がローミングしているかどうかにかかわらず、DN に割り当てられている AAR グループが保持されます。これにより、AAR 宛先番号に対して確立された到達可能性の特性が保持されます。

発信 AAR コールの場合、発信 DN の AAR グループでは、DN の設定ページで選択された AAR グループではなく、ローミング デバイス プールの AAR グループが使用されます。この AAR グループは、ローミング デバイス上のすべての DN に適用されることに注意してください。たとえば、New York から Paris にローミングするデバイス上のすべての DN(どちらの場所も同じデバイス モビリティ グループであることを前提とする)は、Paris デバイス プールの発信コールに対して設定されている AAR グループを継承します。この AAR グループはローミング デバイス上のすべての DN に割り当てられます。また、ローミング電話機上の DN から行われた AAR コールに対して適切なプレフィックスを付加することを許可します。

ローミング中の Call Forward All

デバイスが同一のデバイス モビリティ グループ内をローミングしているとき、Unified CM ではローカル ゲートウェイへの到達にデバイス モビリティ CSS を使用します。ユーザが電話機で Call Forward All を設定している場合、CFA CSS が None に設定されていて、CFA CSS Activation Policy が With Activating Device/Line CSS に設定されていると、次のようになります。

デバイスがホーム ロケーションにあるときに CFA CSS としてデバイス CSS と回線 CSS が使用されます。

デバイスが同一のデバイス モビリティ グループ内をローミングしているとき、CFA CSS としてローミング デバイス プールからのデバイス モビリティ CSS と回線 CSS が使用されます。

デバイスが別のデバイス モビリティ グループ内をローミングしているとき、CFA CSS としてデバイス CSS と回線 CSS が使用されます。

「デバイス モビリティ」の項で、この機能について詳しく説明します。

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

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

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

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

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

図 9-50 エクステンション モビリティと AAR

 

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

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

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

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


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

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


) ただし、エクステンション モビリティ ユーザが自分のホーム サイトと同じ AAR グループに属するリモート サイトに移動した場合には、使用可能な IP WAN 帯域幅が十分にないとき、そのユーザは AAR 機能を使用して他のサイトへのコールを発信できます。これは、コールの発信元の電話機の AAR コーリング サーチ スペースによってそれらのコールのパスが決定されるためです。この AAR コーリング サーチ スペースはユーザがエクステンション モビリティにログイン、またはログアウトしても変更されません。また、このスペースは訪問したリモート サイトのゲートウェイを使用するように設定する必要があります。



ヒント 登録解除されたエクステンション モビリティ プロファイル DN がボイスメールにコールを送信するように設定してください。詳細については、「自動転送コーリング サーチ スペース」を参照してください。

Cisco Unified Mobility 固有の考慮事項

Cisco Unified Mobility(「Cisco Unified Mobility」についての項を参照)では、コールのルーティングに直接影響を与える機能に依存しています。ダイヤル プランに関連する Cisco Unified Mobility パラメータの影響を理解するには、次の例について考えてみます。


) この説明で必要なパラメータのみを、ここで示しています。


ユーザ Paul は、次のように設定された IP Phone を所有しています。

DN:8 555 1234

DID 番号:+1 408 555 1234

外部電話番号マスク:408 555 1234

回線コーリング サーチ スペース:P_L_CSS

デバイス コーリング サーチ スペース:P_D_CSS

Paul の DN は、次のように設定されたリモート宛先プロファイル(RDP)に関連付けられています。

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

再ルーティング コーリング サーチ スペース:P_RDP_Rerouting_CSS

発信側変換 CSS:P_CPT_CSS

Paul の RDP は、次のように設定されたリモート宛先に関連付けられています。

宛先番号:+1 514 000 9876(これは Paul の携帯電話番号。シングルモードまたはデュアルモードのいずれかの電話機)

Paul または Ringo の DID 番号にかけられた PSTN からのコールは、次のように設定されたゲートウェイによって処理されます。

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

有効桁:7

プレフィックス DN:8

ユーザ Ringo は、次のように設定された IP Phone を所有しています。

DN:8 555 0001

DID 番号:408 555 0001

外部電話番号マスク:408 555 0000(これは企業の代表番号)

回線コーリング サーチ スペース:R_L_CSS

デバイス コーリング サーチ スペース:R_D_CSS

次の項では、コール ルーティングでの上記のモビリティ パラメータの影響について説明します。

リモート宛先プロファイル

リモート宛先プロファイル(RDP)はディレクトリ番号(たとえば、ユーザの IP Phone の DN)およびリモート宛先(たとえば、ユーザの携帯電話番号)と関連付けられています。RDP は IP Phone と、リモート宛先として設定された外部番号(たとえば、携帯電話)間のやり取りを制御します。


) リモート宛先は、オンクラスタ DN を宛先番号として設定することはできません。


リモート宛先プロファイルの再ルーティング コーリング サーチ スペース

リモート宛先プロファイルに関連付けられている DN にコールが発信された場合、コールは DN と、リモート宛先として設定されている番号の両方にコールします。

発信者が宛先 IP Phone に到達できるかどうかは、発信者のコーリング サーチ スペース設定によって制御されます。ただし、コールがリモート宛先に分岐(転送)されるかどうか(たとえば、携帯電話)は、着信側モビリティ ユーザの再ルーティング コーリング サーチ スペースによって制御されます。

次に、例を示します。
Ringo は、自分の IP Phone から 8 555 1234 とダイヤルすることによって Paul にコールします。Paul の IP Phone が鳴り、彼の携帯電話も鳴ります。

Ringo が Paul の DN に到達できるかどうかは、Ringo の IP Phone の回線およびデバイス コーリング サーチ スペースによって制御されています。ダイヤルした宛先(8 555 1234)は、連結されたコーリング サーチ スペース R_L_CSS および R_D_CSS にあるパーティションにあります。

このコールが Paul の携帯電話に分岐(転送)されるようにするには、設定されたリモート宛先(+1 514 000 9876)がコーリング サーチ スペース P_RDP_Rerouting_CSS にあるパターンと一致する必要があります。


) Ringo の電話機に割り当てられたダイヤリング特権で外部コールが許可されていなくても、リモート宛先へのコールは、Paul のリモート宛先プロファイルに関連付けられた再ルーティング コーリング サーチ スペースによって処理されます。


リモート宛先プロファイルのコーリング サーチ スペース

Cisco Unified CM 6.0 では、リモート宛先と定義された番号から発信されたコールのルーティングに RDP のコーリング サーチ スペースが使用されます。このスペースは DN の回線 CSS と関連付けられています。連結の順序は、回線 CSS の後に RDP の CSS です。

クラスタに発信された外部コールの発呼側番号がリモート宛先として定義される番号と一致した場合、発呼側番号は、一致したリモート宛先に関連付けられた回線の DN に置き換えられます。また、コールのルーティングに使用されるコーリング サーチ スペースは、次のスペースを連結したものです。

一致したリモート宛先番号に関連付けられた DN の回線コーリング サーチ スペース

一致したリモート宛先に関連付けられた RDP のコーリング サーチ スペース

Unified CM 6.1 およびそれ以降のリリースでは、新しいサービス パラメータ(Inbound Calling Search Space for Remote Destination)が、クラスタのリモート宛先のいずれかから発信されたコールのルーティングに使用されるコーリング サーチ スペースを制御します。デフォルト設定は Trunk or Gateway Inbound Calling Search Space です。これはすべての着信コールをトランクまたはゲートウェイの設定済み CSS を使用してルーティングします。サービス パラメータが Remote Destination Profile + Line Calling Search Space に設定されている場合、動作はすべての Unified CM 6. x リリースで同じになります。この新しいサービス パラメータには、発呼側番号の置換に影響はありません。


) Unified CM 6.1 およびそれ以降のリリースのデフォルト動作は、リモート宛先と定義された番号から発信された着信コールのルーティングに関して、Unified CM 6.0 の動作とは異なります。コールのルーティングが簡素化されるため、シスコは Unified CM 6.1 のデフォルト設定を使用することを推奨します。


同じクラスタ内のリモート宛先として定義されているすべての番号は、クラスタに着信する任意の外部コールで一致するものを検索します。

次の例では、Unified CM 6.1 およびそれ以降のリリースで、Inbound Calling Search Space for Remote Destination サービス パラメータが Trunk or Gateway Inbound Calling Search Space に設定されていることを前提としています。

次に、例を示します。
Paul は、Ringo の卓上電話にコールするために自分の携帯電話を使用しています。コールは PSTN からゲートウェイに着信します。発呼側番号は 514 000 9876 で着信側番号は 408 555 0001 です。コールは Ringo の電話機にルーティングされます。Ringo の電話機に発呼側番号として表示される番号は、Paul の卓上電話番号 8 555 1234 です。これにより、Paul の携帯電話番号は表示されず、Missed および Received コール リストから発信された Ringo のコールが Paul の IP Phone を鳴らします。このようにして企業モビリティ機能の完全なセットが使用できるようになります。

コールがゲートウェイに着信するとき、PSTN では発呼側番号を 514 000 9876、着信側番号を 408 555 0001 と表示します。ゲートウェイの設定は着信番号の末尾から 7 桁の有効桁を保持し、先頭に 8 のプレフィックスを付加し、宛先番号として 8 555 0001 を生成します。

システムは発呼側番号が Paul のリモート宛先番号と一致するかどうかを検出します。一致を検出すると、次の処理が行われます。

1. 発呼側番号を Paul の DN、8 555 1234 に変更します。

2. 着信ゲートウェイのコーリング サーチ スペースを使用して、コールを着信番号にルーティングします。具体的には、ルーティングは GW_CSS コーリング サーチ スペースを介して行われます。

ゲートウェイにより提示される宛先(着信)番号は、電話機の DN である必要があります。また、上記の手順 1 で示した発信側の置換では、Missed/Received コール リストからワンタッチ ダイヤルを使用した方法を示しています。


) リモート宛先番号をパーティションに分類する方法はありません。複数のユーザ グループ(異なる会社、請負業者など)で同じクラスタを使用している場合、この点に注意する必要があります。Unified CM 6.1 およびそれ以降のリリースで、Inbound Calling Search Space for Remote Destination サービス パラメータが Trunk or Gateway Inbound Calling Search Space に設定されている場合、発呼側番号がリモート宛先に一致するかどうかにかかわらず、コールのルーティングは、着信トランクまたはゲートウェイの CSS に基づきます。ただし、発呼側番号の置換は、発信側がリモート宛先に一致した場合でも行われます。これは、テナントのリモート宛先番号から別のテナントの DID 番号へのコールが、発信側のオンネット エクステンション DN と一致する、変換済み発呼側番号で提示されることを意味します。



) 発呼側番号が使用できない着信外部コールは、着信ゲートウェイの CSS に従ってルーティングされます。これは、SIP または H.323 トランクなどの IP トランクからの着信コールにも当てはまります。


リモート宛先プロファイルの発信側変換 CSS とトランスフォーメーション パターン

企業の IP Phone からモビリティ対応の DN に発信されたコールは、企業の宛先 IP Phone の DN と、1 つの(または複数の)外部宛先の両方に分岐(転送)されます。これによる 1 つの課題は、それぞれの宛先電話機のダイヤル プランに適合した発呼側番号を送信することです。これは、Missed および Received コール リストからのコールのリダイヤルを可能にするために必要です。企業の電話機の場合、発呼側番号はリダイヤル可能な企業の電話番号である必要があります。PSTN のリモート宛先の場合(自宅の電話機または携帯電話)、発呼側番号は、発信側 IP Phone と関連付けられている企業の番号から、PSTN からリダイヤル可能な番号(一般に、発信側電話機の DID 番号)に変換する必要があります。

コールがモビリティ対応の企業 DN に発信された場合、発信者の発呼側番号に一致するものを検索するために、関連付けられたリモート宛先プロファイルのコーリング サーチ スペースが使用されます。このスペースには、トランスフォーメーション パターンを含むパーティションが含まれています。

トランスフォーメーション パターンは、企業形式から PSTN 形式への発呼側番号の適合を制御しています。トランスフォーメーション パターンは、着信番号ではなく、発呼側番号をマッチングするという点で、Unified CM の他のすべてのパターンと異なります。マッチング処理は、正規表現(たとえば、8 555 XXXX)を使用して行われます。そして変換処理では、発信側 DN の外部電話番号マスクのほかに、トランスフォーメーション パターンを使用し、番号をプレフィックスとして付加できます。

一致すると、設定済みのすべての変換が実行されます。そして一致したリモート宛先プロファイルに関連付けられているすべてのリモート宛先への到達に、変換後の発呼側番号が使用されます。

次に、例を示します。
Ringo が Paul にコールすると、Paul の IP 電話には発呼側番号が 8 555 0001 と表示され、Paul の携帯電話には 408 555 0001 と表示されるようにします。

この場合、次のパラメータを使用してトランスフォーメーション パターンを作成します。

Pattern:8 555 XXXX

Partition:SJ_Calling_Transform

Use calling party's external phone number mask:チェックしない

Calling Party Transformation mask:555 XXXX

Prefix Digits (outgoing calls):408

パーティション SJ_Calling_Transform がコーリング サーチ スペース P_CPT_CSS に配置されていることを確認する必要もあります。

Ringo からのコールが Paul の電話機にアンカーされている場合、2 つの別々のコール レッグが試行されます。最初のコール レッグは Paul の IP Phone を鳴らし、発信者の DN を発呼側番号(つまり 8 555 0001)と表示します。2 番めのコール レッグは Paul のリモート宛先プロファイルを介して試行されます。参照されるすべてのパーティションのトランスフォーメーション パターン内にある 8 555 0001 の一致を検索するために、RDP の発信側変換 CSS(P_CPT_CSS)が使用されます。パターン 8 555 XXXX はパターン SJ_Calling_Transform でマッチングされます。トランスフォーメーション マスクが発呼側番号に適用され、555 0001 が生成されます。プレフィックス番号が追加され、リモート宛先にコールが発信された場合に変換された発呼側番号 408 555 0001 が使用されます。

この例では、Ringo の DID 番号と異なる番号に設定されているため、外部電話番号マスクを使用していないことに注意してください。これにより、オフネットの宛先に提示される発呼側番号が発信者と着信側で異なっている必要がある場合に、柔軟性が提供されます。Ringo から Paul へのコールは同僚間のものであるため、Ringo の DID 番号が公開されるのは許容されると見なされます。Ringo の次のコールは顧客に対するものである可能性があります。この場合、企業の代表番号 408 555 0000 が、宛先に提示されるのに最も望ましい発呼側番号です。


) 発信側トランスフォーメーション コーリング サーチ スペースには <none> パーティションが暗黙的に含まれていません。そのため、<none> パーティションに残っているトランスフォーメーション パターンはどの発信側トランスフォーメーション コーリング サーチ スペースにも適用されません。これは Unified CM 内の他のすべてのパターンと異なります。Unified CM では、<none> パーティション内に残るすべてのパターンは暗黙的にすべてのコーリング サーチ スペースに含まれます。


アプリケーション ダイヤル ルール

リモート宛先と定義される番号は、着信コールを企業のモビリティ コールとして識別し、アンカリングするためにも使用されます。PSTN がコールを識別する形式は、企業のダイヤル プランがコールを外部番号にダイヤルする場合の形式と異なることがよくあります。適用ダイヤル規則は、リモート宛先で、コールをリモート宛先に分岐(転送)する際に必要な形式に設定するために使用できます。これらの規則では、リモート宛先として設定された番号から、数字を削除したり、数字をプレフィックスとして付加したりできます。

次に、例を示します。
番号 514 000 9876 は Paul のリモート宛先番号として設定されています。この番号は、企業に着信するコールを識別するために PSTN が使用する形式に対応します。ただしこれは、発信コールで企業のダイヤル プランが使用する形式(91 をプレフィックスとして付加する必要があります)とは異なります。この場合、リモート宛先の形式を企業ダイヤル プランの形式に適合させるために、適用ダイヤル規則を作成する必要があります。

適用ダイヤル規則:

名前:514000_ten

説明:プレフィックス 91 を 514000 で始まる 10 桁の番号に付加するために使用

番号の先頭:514000

桁数:10

削除する桁数:0

パターンで付加するプレフィックス:91

この例では、Paul の携帯電話から企業へかけられたコールは、514 000 9876 からのものと識別されます。これは、Paul の番号がリモート宛先と設定されている形式に一致します。このため、マッチングが行われ、Paul の卓上電話コールのアンカリングをトリガーします。またオンネットの宛先に表示される発呼側番号の最適化も行われます (たとえば、コールが Ringo の DID 番号に対して行われた場合、Ringo にはその着信が 8 555 1234 から来たものと表示されます)。

コールが Paul の企業 DN 番号に対して行われた場合、Paul のリモート宛先番号に分岐(転送)されたコール レッグは、上記の適用ダイヤル規則によって処理されます。ストリング 514 000 は Paul のリモート宛先番号の先頭と一致します。また、この番号は 10 桁であるため、数字は削除されず、91 がプレフィックスとして付加されます。これにより、Paul のリモート宛先プロファイル コーリング サーチ スペース(この場合は P_RDP_CSS)を介してルーティングされる番号として、91 514 000 9876 が生成されます。


) このアプローチでは、IP Phone から行われたコールのルーティングのためにすでに定義済みのコーリング サーチ スペースを再利用する機能を提供します。発信コールに対してプレフィックスを付加する必要のない新しいコーリング サーチ スペース(つまり、直接 514 000 9876 にコールをルーティングできる)は好ましくありません。外部パターンとオンネット パターンが重複する状況が発生する可能性があるためです。


即転送(iDivert)

即転送(iDivert)機能は、コールを直接ボイスメールに送信するために使用します。コールが鳴っているとき(着信)、コールが保留中のとき、またはコールが接続されたときに呼び出すことができます。iDivert 機能では、着信コールが呼び出した電話機のボイスメール ボックスまたは着信側のボイスメール ボックスのいずれかに迂回されます。拡張機能は、転送されたコールやアプリケーションによってリダイレクトされたコールなどの迂回されたコールにのみ適用可能です。

Cisco Unified CM 5.1 の iDivert 機能拡張

iDivert 機能は Cisco Unified CM 5.1 で拡張され、呼び出した電話機のボイスメール ボックス(従来の処理)または着信側のボイスメール ボックス(拡張された処理)のいずれかに着信コールを迂回させることができるようになりました。拡張機能は、転送されたコールやアプリケーションによってリダイレクトされたコールなどの迂回されたコールにのみ適用可能です。

次に、例を示します。

電話機 A が電話機 B にコールするとします(電話機 B のコールは電話機 C に転送されます)。電話機 C が鳴っているとき、電話機 C 側にいるユーザは [iDivert] ソフトキーをアクティブにします。これにより、2 つの選択肢が提供されます。1 つめの選択肢では、コールが発信側のボイスメール(この場合、電話機 B のボイスメール ボックス)に送信されます。2 つめの選択肢では、コールが iDivert 呼び出し側のボイスメール(この場合、電話機 C のボイスメール ボックス)に送信されます。コールが鳴っているとき、接続中、または保留中の場合のいずれかに、電話機 C がこの機能を呼び出しても、同じ選択肢を選択できます。

iDivert 機能を呼び出す前に、コールが Auto Call Pickup、Call Transfer、Call Park、Call Park Reversion、Conference、または MeetMe Conference によって処理されると、コールは「迂回された」コールとは見なされなくなり、この場合で使用できる iDivert 機能は、従来の iDivert 処理だけになります(つまり、コールを呼び出し側のボイスメールに送信します)。たとえば、電話機 A が電話機 B にコールするとします。電話機 B のコールは電話機 C に転送され、その後電話機 C はコールを電話機 D に転送します。コールに適用された最後のアクションが電話機 D への転送であるため、これは迂回されたコールでは ありません 。電話機 D が iDivert 機能を呼び出すと、コールは電話機 D のボイスメール ボックスに送信されます。

上で説明した iDivert の完全な機能を有効にするには、Unified CM サービス パラメータ Use Legacy Immediate Divert False に設定します。有効にすると、拡張された iDivert は自動的に QSIG トランクを介してこの機能を使用することを許可します。このため、呼び出し側のボイスメール ボックスが、QSIG を介して接続されているテレフォニー システムでホストできます。

iDivert が、QSIG を使用して他の電話システムに接続しているクラスタで使用されている場合、コールを受信したときにレガシー iDivert 機能のみ(使用できる選択肢はコールを呼び出し側のボイスメールに送信することのみ)が電話機に提供されます。たとえば、電話機 A および B がクラスタ 1 にあり、電話機 X が QSIG に接続された別のテレフォニー システムであるとします。電話機 A が電話機 X にコールし、電話機 X のコールが電話機 C に転送されます。コールが電話機 C に接続されると、iDivert は、QSIG パスの置き換えが実行されていない場合に限り、レガシー(呼び出し側のボイスメール)と拡張(着信側のボイスメール)の宛先の両方を提供します。QSIG パスの置き換え後、電話機 C が iDivert を呼び出した場合、選択可能な宛先は電話機 C のボイスメール ボックスのみです。

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

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

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

図 9-51 Unified CM のハント コンストラクトの 3 層式アーキテクチャ

 

ハント パイロット

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

ハンティングが次のいずれかまたは両方の理由で失敗した場合、コールを最終的な宛先にリダイレクトできます。

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

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

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

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

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

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

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

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

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

ハント リスト

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

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

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

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

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

回線グループ

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

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

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

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

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

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

トップダウン

循環

最長アイドル時間

ブロードキャスト

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

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

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

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

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

ハント グループのログアウト

ユーザは、[HLog] ソフトキーをアクティブにすることによって、ハント グループからログアウトできます。いったんアクティブにすると、この機能では実質的に、電話機上で設定されているすべての回線が、どのハント グループにも含まれていないように動作させます。電話機には「Logged out of Hunt Group」と表示されます。回線グループにシェアド ラインが含まれている場合、デバイス上でログアウト状態のシェアド ラインのすべてのインスタンスは呼び出されません。反対に、デバイス上でログイン状態のシェアド ラインのすべてのインスタンスは呼び出されます。

どのハント グループにも含まれていない回線は、HLog 機能の状態に関係なく、通常どおり呼び出されます。

HLog 機能は Unified CM Administration からアクティブにできます。デフォルトでは、[HLog] ソフトキーはソフトキー テンプレートでは設定されません。いったん、ソフトキー テンプレートに追加されると、電話機が接続状態、保留状態、またはオンフック状態のときに [HLog] ボタンがディスプレイに表示されます。

Hunt Group Logoff Notification サービス パラメータでは、回線グループから来るコールがログオフ状態の電話機に着信した場合の着信音による通知オプションを提供します。Hunt Group Logoff Notification サービス パラメータは、[Service Parameters Configuration] ページの Clusterwide Parameters (Device - Phone) セクションにあります。この機能を有効にするには、TFTP サーバ上に有効な着信音ファイルがあることを確認してください。無効なファイル名が指定されると、何も音が再生されません。

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

http://www.cisco.com

回線グループ デバイス

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

Skinny Client Control Protocol(SCCP)エンドポイント(Cisco Unified IP Phones など)

SIP エンドポイント

ボイスメール ポート(Cisco Unity)

H.323 クライアント

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

時間帯ルーティング

この機能を使用するには、次の要素を設定します。

期間

タイム スケジュール

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

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

図 9-52 では、同じコール パターン(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 日は非アクティブです。

図 9-52 時間帯ルーティング

 

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

論理パーティション

論理パーティションには、次の要素が含まれます。

デバイス タイプ。電話機は interior として分類され、ゲートウェイとトランクは border として定義されます。 表 9-9 に、各デバイスのエンドポイント タイプを示します。

ジオロケーション。エンドポイントにはポリシーの決定に使用される住所が割り当てられます。

ジオロケーション フィルタ。ポリシーの決定は、ジオロケーション オブジェクトのサブセットに対して行うことができます。

ポリシー。エンドポイント間の通信は、それらの相対的な(フィルタ処理された)ジオロケーションとデバイス タイプに基づいて許可または拒否されます。


) コールのすべての参加者が interior として分類されないと、ポリシーは適用されません。つまり、同じクラスタにある電話機間のコールに論理パーティション ポリシーが適用されることはありません。



) ジオロケーションは、Unified CM で設定するコール アドミッション制御用のロケーションや、デバイス モビリティに使用される物理ロケーションと混同しないでください。


 

表 9-9 デバイス タイプ

論理パーティションのデバイス タイプ
Cisco Unified Communications Manager デバイス

Border

ゲートウェイ(H.323 ゲートウェイなど)

Inter-cluster Trunk(ICT)(ゲートキーパー制御および非ゲートキーパー制御の両方)

H.225 トランク

SIP トランク

MGCP ポート(E1、T1、PRI、BRI、FXO)

Interior

電話機(SCCP、SIP、またはサードパーティ)

CTI ルート ポイント

VG224 アナログ電話

MGCP ポート(FXS)

Cisco Unity ボイスメール(SCCP)

論理パーティションのデバイス タイプ

Unified CM は、エンドポイントを interior または border に分類します。この分類は固定されており、システム管理者が変更することはできません。

ジオロケーションの作成

(RFC) 4119 規格には、ジオロケーションの基本情報が記載されています。ジオロケーションには、次のオブジェクトによって指定される住所形式が使用されます。

名前

説明

2 文字の短縮形を使用した国名

州、地区、または地域(A1)

国または行政区(A2)

市町村(A3)

自治区(A4)

地区(A5)

街(A6)

N や W など、街の先頭の方角指示(PRD)

SW など、街の末尾のサフィックス(POD)

通りや区画など、住所のサフィックス(STS)

番地(HNO)

A、1/2 など、番地のサフィックス(HNS)

ランドマーク(LMK)

部屋番号など、ロケーションの補足情報(LOC)

フロア(FLR)

会社または居住者の名前(NAM)

郵便番号(PC)


) Unified CM では、ジオロケーションを手動で定義する必要があります。


ジオロケーションの割り当て

デバイスには、優先順位に従ってデバイス ページ、デバイス プール、またはエンタープライズ パラメータで設定されたデフォルトのジオロケーションのいずれかからジオロケーションが割り当てられています。

ジオロケーション フィルタの作成

ジオロケーション フィルタでは、異なるエンドポイントのジオロケーションを比較するときに使用するジオロケーション オブジェクトを定義します。たとえば、電話機のグループには、それらの電話機が置かれている部屋やフロアを除いて、同じジオロケーションが割り当てられる可能性があります。ポリシーによっては、同じ建物内のエンドポイントを同じ非公開ユーザ グループに所属するものと見なし、通信を許可する場合もあります。各電話の実際のジオロケーションは異なりますが、フィルタ処理されたジオロケーションは同じになります。この方法は、ジオロケーションの最上位のフィールドだけにポリシーを適用する必要がある場合に役立ちます。たとえば、異なる都市にある電話機とゲートウェイ間の通信を拒否し、同じ都市内の電話機とゲートウェイ間の通信は許可するポリシーは、都市よりも詳細なオブジェクトを無視してフィルタ処理された相対的なジオロケーションを基にできます。

ジオロケーション フィルタの割り当て

電話機は、デバイス プールのフィルタの割り当てを継承します。ゲートウェイとトランクには、優先順位に従ってデバイスまたはデバイス プール レベルでジオロケーション フィルタを設定できます。

論理パーティション ポリシーの設定

論理パーティション ポリシーは、ジオロケーション ID 間に設定されます。ジオロケーション ID は、フィルタ処理されたジオロケーションとデバイス タイプの組み合わせになります。フィルタ処理されたジオロケーションを取得するには、デバイスのジオロケーションを呼び出し、デバイスに関連付けられたジオロケーション フィルタを適用します。

ポリシーは、ジオロケーション オブジェクトのセットとデバイス タイプの組み合わせ(ソース ジオロケーション ID)として、そのようなもう 1 つの組み合わせ(ターゲット ジオロケーション ID)と関係付けて作成されます。関係が一致すると、設定されている「許可」または「拒否」の処理がコール レッグに適用されます。


) ポリシーに設定されているジオロケーション オブジェクトのセットはそれぞれ、1 つのデバイス タイプに関連して考慮されます。たとえば、国 = インド、州 = カルナタカ、市 = バンガロールのようなジオロケーション オブジェクトのセットは、バンガロールの電話機に対する処理に関してはデバイス タイプ Interior に関連付ける必要があり、バンガロールのゲートウェイに対する処理に関してはデバイス タイプ Border に別に関連付ける必要があります。


論理パーティション ポリシーの適用

ユーザの操作によって新しいコール レッグが作成された場合(たとえば、ユーザが第 3 の発信者を既存のコールに参加させる場合)、Unified CM は各参加者ペアのジオロケーション ID と事前に設定されたポリシーのジオロケーション ID を照合します。


) 2 つのデバイスのジオロケーション ID が論理パーティションによって評価されている場合、両方のデバイスのデバイス タイプが Interior であれば、ポリシーは適用されません。つまり、同じクラスタ内の IP 電話間のコール、会議、転送などが論理パーティション ポリシーによって拒否されることはありません。


たとえば、インドのバンガロールにある電話機 A と B、およびカナダのオタワにあるゲートウェイ C について考えます。電話機 A から電話機 B にコールします。いずれのデバイスのタイプも Interior であるため、ポリシーは呼び出されません。コールが確立され、次に電話機 A のユーザが会議を起動し、それによってゲートウェイ C が引き込まれます。処理が許可される前に、Unified CM は A と C のジオロケーション ID、および B と C のジオロケーション ID をチェックして、事前に設定されたポリシーとの照合を行います。ポリシーの一致によって処理が拒否された場合、新しいコール レッグは確立できません。


) Unified CM のデフォルト ポリシーは拒否です。つまり、コール レッグを許可するように明示的にポリシーを設定していなければ、コール レッグは拒否されます。


この例では、バンガロールの Interior デバイスがオタワの Border デバイスに接続できるように明示的にポリシーを設定していない限り、コール レッグは拒否されます。

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 つのタイプがあります。

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

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

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

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

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

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

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

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

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

図 9-53 着信ダイヤル ピアと発信ダイヤル ピア

 

着信コール レッグを着信ダイヤル ピアと対応付けるために、ルータは、セットアップ メッセージ内の情報要素(着信番号/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.... を使用して設定され、 別のダイヤル ピアが 3456789 を使用して設定されている場合、ルータはまず 3456789 を選択します。2 つのダイヤル ピアのうち、正確に一致している部分が最も長いためです。

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

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

3. ランダム選択

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

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

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

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

dial-peer voice 999 pots
incoming called-number .
direct-inward-dial
port 1/0:23
 

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

dial-peer voice 100 voip
preference 1
 
!--- Make this the first choice dial peer.
 
ip precedence 5
destination-pattern 1...
session target ipv4:10.10.10.2
 
!--- This is the address of the primary Unified CM.
 
dtmf-relay h245-alpha
 
 
dial-peer voice 101 voip
preference 2
 
!--- This is the second choice.
 
ip precedence 5
destination-pattern 1...
session target ipv4:10.10.10.3
 
!--- This is the address of the secondary Unified CM.
 
dtmf-relay h245-alpha
 

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

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

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

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

http://www.cisco.com

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

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

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

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

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

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

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

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

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

ドット(.)ワイルドカード。いずれかの 1 桁の 0 ~ 9 までの数字に対応

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

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

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

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

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

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

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

図 9-54 ARQ のゲートキーパー アドレス解決

 

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

図 9-55 LRQ のゲートキーパー アドレス解決

 

従来の Cisco IOS ゲートキーパー機能は、 中継ゾーン ゲートキーパー という概念を通じて、Cisco Unified Border Element に対応するように拡張されました。

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

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

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

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

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

 

例 9-5 では、図 9-56 のゲートキーパー設定を示しています。

例 9-5 集中型ゲートキーパーの設定

gatekeeper
zone local GK-Site1 customer.com 10.1.10.100
zone local GK-Site2 customer.com
zone prefix GK-Site1 408.......
zone prefix GK-Site2 212.......
bandwidth interzone GK-Site1 160
bandwidth interzone GK-Site2 160
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
 

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

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

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

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

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

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

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

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

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

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

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

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

 

例 9-6 では、図 9-57 のサイト 1 に対するゲートキーパー設定を示しています。

例 9-6 サイト 1 のゲートキーパー設定

gatekeeper
zone local GK-Site1 customer.com 10.1.10.100
zone remote GK-Site2 customer.com 10.1.11.100
zone prefix GK-Site1 408.......
zone prefix GK-Site2 212.......
bandwidth remote 160
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
 

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

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

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

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

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

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

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

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

例 9-7 サイト 2 のゲートキーパー設定

gatekeeper
zone local GK-Site2 customer.com 10.1.11.100
zone remote GK-Site1 customer.com 10.1.10.100
zone prefix GK-Site2 212.......
zone prefix GK-Site1 408.......
bandwidth remote 160
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

gatekeeper
zone local GK-Site1 customer.com 10.1.10.100
zone remote DGK customer.com 10.1.10.101
zone prefix GK-Site1 408.......
zone prefix DGK ..........
bandwidth remote 160
gw-type-prefix 1#* default-technology
arq reject-unknown-prefix
no shutdown
 

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

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

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

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

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

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

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

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

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

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

gatekeeper
zone local DGK customer.com 10.1.10.101
zone remote GK-Site1 customer.com 10.1.10.100
zone remote GK-Site2 customer.com 10.1.11.100
zone prefix GK-Site1 408*
zone prefix GK-Site2 212*
lrq forward-queries
no shutdown
 

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

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

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

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

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

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

H.323 を使用する Cisco IOS ベースのシステム(H.323 ゲートウェイ、SRST、および Cisco Unified Communications Manager Express(Unified CME)を含む)にコール特権を実装するには、制限クラス(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 リストの内容にかかわらず、他のすべてのダイヤル ピアがこのダイヤル ピアにアクセスできます。

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

図 9-59 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 リストがすべて持っている必要があります。

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

次に、宛先が 200 になっている別の 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 CM クラスタへの接続を失うときまで、個々の 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 Communications Manager Express(Unified CME)にも配置できます。個々の IP Phone は、Unified CME で具体的に設定されます。したがって、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 System Administrator Guide 』および『 Cisco Unified Communications Manager Express 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 桁の内線番号をダイヤルすると、別のサイトにいる従業員に到達できるとします。コールが他のサイトに PSTN を通じてルーティングされ、到達する場合は、発信側のゲートウェイで音声トランスレーション プロファイルを使用する必要があります。これによって、5 桁の内線番号が PSTN で認識される 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 にある単純な配置について考えます。 表 9-10 では、この例の DID 範囲と内部サイト コードを示しています。

表 9-10 変換ルール応用例の DID 範囲とサイト コード

San Jose
San Francisco
New York
Dallas

DID 範囲

(408) 555-1XXX

(415) 555-1XXX

(212) 555-1XXX

(972) 555-1XXX

サイト コード

1

2

3

4

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

voice translation-rule 1
rule 1 /^81/ /91408555/
rule 2 /^83/ /91212555/
rule 3 /^84/ /91972555/
 
voice translation-profile on-net-xlate
translate called 1
 
call-manager-fallback
translation-profile outgoing on-net-xlate
 
dial-peer voice 2 pots
destination-pattern 91[2-9]..[2-9]......
port 1/0:0
direct-inward-dial
forward-digits 11
 

この設定では、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 サイトで入手可能な『 Cisco IOS Terminal Services Configuration Guide 』の「 Regular Expressions 」を参照してください。

http://www.cisco.com/en/US/docs/ios/termserv/configuration/guide/tsv_reg_express_ps6441_TSD_Products_Configuration_Guide_Chapter.html

Service Advertisement Framework(SAF)Call Control Discovery(CCD)

この項では、Unified CM および関連する Unified Communications サブシステムにおける Service Advertisement Framework(SAF)呼制御ディスカバリ(CCD)サービス設定に関して、いくつかの点に重点を置いて説明します。このテーマの詳細については、「Service Advertisement Framework の呼制御ディスカバリを使用したコール ルーティングおよびダイヤル プラン配信」の項、および次の URL にある最新バージョンの『 Cisco Unified Communications Manager Administration Guide 』を参照してください。

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

Unified CM クラスタは、CCD アドバタイザとしてフレームワークに参加することによって、ホストする DN 範囲に関する情報をネットワークに挿入します。この情報は Service Advertisement Framework フォワーダ(SAF フォワーダ)に送信されます。SAF フォワーダは、新しいルートを取得し、それらをネットワーク内の参加している他の SAF フォワーダや CCD リクエスタと共有します。

Unified CM クラスタは、CCD リクエスタとしてフレームワークに参加することによって、ネットワーク内の他のコール エージェントによってアドバタイズされた DN 範囲を SAF フォワーダから取得します。

SAF フォワーダ

SAF フォワーダは Cisco IOS ルータに設定します。SAF フォワーダには Cisco IOS Release 15.0(1) 以降が必要です。SAF フォワーダの設定の詳細については、次の URL にある『 Cisco IOS Service Advertisement Framework Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10591/products_installation_and_configuration_guides_list.html

SAF フォワーダの設定

Unified CM では、SAF セキュリティ プロファイル([Advanced Features] > [SAF] > [SAF Security Profile])および SAF フォワーダ([Advanced Features] > [SAF] > [SAF Forwarder])の両方を設定する必要があります。

Unified CM の [SAF Security Profile] 設定ページには、[User Name] フィールドと [User Password] フィールドがあります。これらのエントリは、Cisco IOS コマンドライン インターフェイス(CLI)での SAF フォワーダ設定と一致する必要があります。

また、[SAF Forwarder] 設定ページで設定された [Unified CM Client Label] は、SAF フォワーダの CLI 設定の external-client 文のいずれかと一致する必要があります。次に、例を示します。

router eigrp
service-family ipv4 autonomous-system 1
!
topology base
external-client sample_client_label
exit-sf-topology
exit-service-family
!
 
service-family external-client listen ipv4 5050
external-client sample_client_label
username sample_user_name
password sample_user_password
keepalive 10000
!
 

詳細については、次の URL にある『 Cisco IOS Service Advertisement Framework Configuration Guide 』を参照してください。

http://www.cisco.com/en/US/products/ps10591/products_installation_and_configuration_guides_list.html

要求サービス

SAF CCD から取得された DN 範囲は、要求元クラスタの専用の CCD コール ルーティング パーティションに設定されます。取得された DN 範囲は、1 つ以上の CCD トランクに関連付けられています。CCD から取得された DN 範囲へのコールは、要求サービスに関連付けられた CCD トランクから発信されます。CCD トランクと要求サービスの関連付けは、Unified CM の [Call Routing] > [Call Control Discovery] > [Requesting Service] にある [CCD Requesting Service Info] ページの [Selected SAF Trunks] フィールドで行います。

クラスタと SAF フォワーダとの間で交換される CCD レコードには、DN 範囲、DN 範囲をホストするコール エージェント ノードの IP アドレス、コールを PSTN に再ルーティングするときに DN を適合させるための番号操作ルール、およびこの DN 範囲をコールするために必要な IP シグナリング プロトコルに関する情報が含まれています。

たとえば、クラスタ A には DN 範囲 8555XXXX がホストされ、PSTN における対応する DID 範囲は +1415555XXXX であるとします。この DN 範囲の IP コールの受信に指定された CCD トランクに関連付けられているクラスタ A サブスクライバの IP アドレスは 10.1.1.1 です。この DN 範囲に到達するために必要なプロトコルは SIP です。この場合、この DN 範囲に関連付けられた CCD レコードは、次のように表すことができます。

 

DN 範囲
ToDID
IP
プロトコル

8555XXXX

1:+1415

10.1.1.1

SIP

DN 範囲

ユーザが 85551234 にダイヤルすると、8555XXXX に一致し、85551234 へのコールはこのパターンをアドバタイズしたクラスタに発信されます。

ToDID

このフィールドは、PSTN 経由で DN 範囲に到達するためのルールを表しています。ユーザが 85551234 にダイヤルし、コールが CCD トランク経由でルーティングできない場合、ToDID ルールが適用されて、宛先番号が PSTN に互換性がある形式に変換されます。たとえば、範囲 8555XXXX にルール 1:+1415 が適用されると、左端の 1 桁が削除されて、+1415 が先頭に付加されます。その結果 +14155551234 という番号が生成されます。この番号を使用すると、次の場合に発信側クラスタ内の任意のゲートウェイにコールをルーティングできます。+E.164 形式でコールをルーティングするようにプロビジョニングされており、グローバルな +E.164 形式の番号を PSTN キャリアで受け付けられるローカル形式に適合させるための適切な着信側トランスフォーメーション パターンでゲートウェイがプロビジョニングされている場合です。

IP

宛先 DN をホストするコール エージェント ノードの IP アドレスは、発信側クラスタ内で関連する CCD トランク経由でコールを発信する場合に使用されます。

プロトコル

この場合、DN 範囲をホストするコール エージェントによってアドバタイズされるプロトコルは SIP です。H.323 が使用されることもあります。

特定のクラスタでどのような SAF CCD レコードが検出されたかを表示するには、Cisco Unified CM Real-Time Monitoring Tool(RTMT)を使用します。このツールでは、検出された DN 範囲、および SAF フォワーダとクラスタとの関連付けに関する情報が提供されます。

Business Edition 3000 のダイヤル プランに関する考慮事項

Cisco Business Edition 3000 では、ドロワー ユーザ インターフェイス(GUI)とともに非常に単純化されたフロント エンドが提供されます。サイト プロファイルや使用プロファイルなどの新しいコンセプトが導入されました。回線/デバイス アプローチとコーリング サーチ スペースを使用するダイヤル プランの基本的なコンセプトは同じですが、Business Edition 3000 ではサイトとプロファイルのコンセプトを使用してダイヤル プランが実装されます。次のように、デバイス レベルのコール特権はサイトによって定義され、回線レベルのコール特権に対する制限は使用プロファイルによって定義されます。

サイト

サイトは、電話機、ユーザ、ゲートウェイなどを含むエンドポイントの地理的なグループを表します。サイトには特権が与えられ、そのサイトの各ユーザが使用できるコール特権の最大レベルが定義されます。これは、各ユーザがこれらの特権を持つのではなく、特権がコールを発信する各ロケーションの機能を制御することを意味します。たとえば、国際番号をダイヤルするコール特権を持つロケーションがあるとしても、これは必ずしもこのサイトの各ユーザが国際コールを発信できることを意味しません。

使用プロファイル

使用プロファイルを使用すると、システム管理者は電話機のほとんどのユーザ設定を一箇所で行うことができます。管理者は、既存の使用プロファイルを編集したり、既存の使用プロファイルを複製して新しいプロファイルを作成したり、完全に新しい使用プロファイルを追加したりできます。各使用プロファイルは一意の名前を持ちます。使用プロファイルの設定後に、システム管理者は使用プロファイルをユーザまたは配置に割り当て、ユーザ プロファイルの設定を個々のユーザまたは全体の部門に属する電話機に適用できます。

使用プロファイルでは、割り込みや Cisco Extension Mobility などの電話機機能、電話機ハードウェア機能、電話機に表示できる電話機アプリケーション、電話機に表示されるボタンと機能ボタンの順序を制御する電話機ボタン テンプレートなどのユーザのコール特権を設定できます。


) Cisco Business Edition 3000 は、最大 10 個の使用プロファイルをサポートします。


サイト特権と使用コール特権の組み合わせにより、ユーザが番号をダイヤルする実際の機能が定義されます。たとえば、サイトにはコールの最大レベルとして国際コールをダイヤルする特権を割り当てることができます。この場合、ユーザは国際コール、長距離コール、およびローカル コールを含む任意の番号をダイヤルできます。ただし、ユーザが、ダイヤル特権をローカル コールだけに制限する使用プロファイルに割り当てられている場合、サイトが国際コールをダイヤルする特権を持っていても、そのユーザはローカル コールだけをダイヤルできます。

別の例として、ユーザが、国際コールをダイヤルするコール特権を持つ使用プロファイルとサイトに割り当てられているとします。このユーザが、サイト レベル特権がローカル コールへのダイヤルだけに制限された別のサイトに移動した場合、このユーザはローカル コール以外にダイヤルすることはできません。これは、現在のサイト レベル コール特権により許可されないためです。

実際には、サイト レベル コール特権と使用プロファイル コール特権を下げることによって、ユーザのコール特権が決まります。

変換ルール

変換ルールにより、Cisco Business Edition 3000 はシステムの一部である着信電話番号を操作し、コールのルーティング前に内線に変換できます。システムに着信したコールと IP 電話機により生成されたコールは設定された変換ルールに基づいて照合され、番号が一致すると、変換が実行されます。


) Business Edition 3000 では、変換ルールでのワイルド カードの使用はサポートされていません。


論理パーティション

各電話機は、電話機で設定された IP アドレスに基づいてサイトに関連付けられます。各サイトは 1 つまたは複数のサブネットにマップされます。電話機の IP アドレスがこれらいずれかのサブネット内に存在する場合、電話機はサブネットがマップされたサイトに属します。電話機がシステム定義されていない IP アドレスを取得した場合は、電話機は中央サイトの一部であると見なされます。ただし、テレワーカー サイトが設定されている場合は、設定された IP アドレスが設定されたいずれかのサブネット内に存在しない電話機がテレワーカー電話機と見なされます。

設定されたサイトは論理パーティションをサポートします。サイトの設定時に、管理者は PSTN 特権を設定する必要があります。中央サイト PSTN へのアクセスが設定されていない場合、リモート サイトのユーザは PSTN コール レッグが関係する会話に参加できません。また、リモート サイト電話機は PSTN コールを開始することができません。