Cisco Collaboration 9.xソリューション リファレンス ネットワーク デザイン(SRND)
ダイヤル プラン
ダイヤル プラン
発行日;2013/10/03 | 英語版ドキュメント(2013/09/09 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 30MB) | フィードバック

目次

ダイヤル プラン

この章の新規情報

ダイヤル プランの基本

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

数値アドレス(番号)

英数字のアドレス

ダイヤリング手順

ダイヤル ドメイン

サービス クラス(COS)

コール ルーティング

ダイヤリング手順の特定と、オーバーラップの回避

強制オンネット ルーティング

1 つの呼制御のコール ルーティング

複数の呼制御のコール ルーティング

ダイヤル プランの要素

Cisco Unified Communications Manager

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

IP Phone での発信側の変換

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

SCCP 電話機でのユーザ入力

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

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

SIP ダイヤル規則

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

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

Directory URI

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

UnifiedCM の外部ルート

緊急パターン

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

着信の発呼側設定(ゲートウェイまたはトランク別)

着信の着呼側設定(ゲートウェイまたはトランク別)

UnifiedCM におけるコール特権

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

Cisco TelePresence Video Communication Server

Cisco VCS アドレッシング方式:SIP URI、H.323 ID、E.164 エイリアス

Cisco VCS アドレッシング ゾーン

Cisco VCS のパターン マッチング

Cisco VCS のルーティング プロセス

推奨される設計

Unified CM のグローバル化されたダイヤル プラン アプローチ

ローカル ルート グループ

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

発番号変換

着番号変換

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

論理パーティション

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

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

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

グローバル化されたダイヤル プランのコール ルーティング

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

Unified Communications Manager と TelePresence Video Communication Server の統合

+E.164 番号計画

エイリアスの正規化と操作

エンドポイント SIP URI の実装

特記事項

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

宛先 PSTN 番号の確立

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

ボイスメールの考慮事項

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

デバイス モビリティ

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

Cisco Unified Mobility 固有の考慮事項

リモート宛先プロファイル

リモート宛先プロファイルの再ルーティング コーリング サーチ スペース

リモート宛先プロファイルのコーリング サーチ スペース

リモート宛先プロファイルの発信側変換 CSS とトランスフォーメーション パターン

アプリケーション ダイヤル ルール

時間帯ルーティング

論理パーティション

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

ジオロケーションの作成

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

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

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

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

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

ダイヤル プラン

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

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

呼処理エージェントに登録された宛先に、到達可能性を実現するためにアドレスが割り当てられます。これらの内部の宛先には、すべてのエンドポイント(IP Phone、ビデオ エンドポイント、ソフト クライアント、アナログ エンドポイントなど)とアプリケーション(ボイスメール システム、自動転送、会議システムなど)が含まれます。

パスの選択

発信元デバイスとダイヤルされた宛先に応じて、ダイヤルされた宛先へのパスが選択されます。セカンダリ パスを使用できる場合、このパスもプライマリ パスに障害が発生したときに検討対象になります。

コール特権

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

ダイヤルされた宛先の操作

ダイヤルしているデバイスからダイヤルされた宛先へのパスで、ダイヤル プランはダイヤルされた宛先に操作を適用できます。たとえば、ドイツの PSTN の宛先に到達するために、米国のユーザは 9011496901234 をダイヤルしますが、一方でフランスのユーザは 000496901234 をダイヤルすると同じ宛先に到達することができる場合があります。このダイヤルされる宛先は、米国のゲートウェイの PSTN トランクには 011496901234 として示され、フランスにあるゲートウェイの PSTN トランクには 00496901234 として示される必要があります。

コールに関連する ID 情報の表示

セッションの確立中とコール中に、発信側および着信側デバイスで、他のデバイスに関する情報が表示されます。コールの状態および方向に応じて、発信元、転送元、アラート側、接続先の情報が含まれます。ダイヤル プランで、表示される情報の形式と内容に影響するマッピングを定義できます。

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

「ダイヤル プランの基本」

ここでは、企業向け音声およびビデオ ダイヤル プランでよく使用される一般的な概念について説明します。

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

ここでは、Cisco Unified Communications Manager(Cisco Unified CM)と Cisco TelePresence Video Communication Server(VCS)を含む企業向けコラボレーション ソリューションのアーキテクチャ要素で使用できる各ダイヤル プラン要素を説明します。

「推奨される設計」

ここでは、マルチ サイト コラボレーション ネットワーク、エンドポイントのアドレッシング、サービス クラスの構築に関連する設計ガイドラインを説明します。また、Unified CM と VCS のダイヤル プランの統合についても説明します。

「特記事項」

詳細については、次の Web サイトから入手可能な『 Cisco Unified Communications Manager System Guide 』、『 Cisco Unified Communications Manager Features and Services Guide 』、Cisco IOS の音声およびビデオ コンフィギュレーション ガイド、およびその他の製品マニュアルを参照してください。

http://www.cisco.com

この章の新規情報

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

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

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

この章の大きな再編成および改訂

この章のすべての項

2013 年 4 月 2 日

このマニュアルで説明しないようになったトピックは次のとおりです。

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

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

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

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

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

この情報については、次の URL にある『 Cisco Unified Communications System 9.0 SRND 』の「 Dial Plan 」の章を参照してください。

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/dialplan.html

2013 年 4 月 2 日

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

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

2012 年 10 月 31 日

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

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

2012 年 6 月 28 日

URI ダイヤル

「Directory URI」

2012 年 6 月 28 日

SIP 要求のルーティング

「Unified CM におけるコール特権」

2012 年 6 月 28 日

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

この章の各項で説明

2012 年 6 月 28 日

ダイヤル プランの基本

エンドツーエンドの企業のダイヤル プランの開発には、特定の製品にも依存しないいくつかの概念の確実な知識が必要です。ここでは、次のような、これらの概念の概要を提供します。

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

「ダイヤリング手順」

「ダイヤル ドメイン」

「サービス クラス(COS)」

「コール ルーティング」

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

呼処理エージェントに登録されているエンドポイント、ユーザ、およびアプリケーションの到達可能性は、アドレス指定可能なエンティティに割り当てられたアドレスによって提供されます。企業のコラボレーション ネットワークで、数値アドレスと英数字の Uniform Resource Identifier(URI)は区別されます。

数値アドレス(番号)

数値アドレスは一連の数字で表されます。呼制御エージェントでは、数値アドレスに対して、特殊な構造を前提としたり、排除したりせず、必須のものでもありません。ダイヤル プランで使用される数値アドレス構造の決定は、ダイヤル プランの設計プロセスの一部です。

ITU 勧告 E.164 は、図 14-1 に示すように、PSTN で使用される数値の地理的アドレス(電話番号)の基本構造を定義します。

図 14-1 地理的な番号の E.164 形式

 

CC

1 ~ 3 桁

NSN

最大 15-n 桁(n = CC の桁)

NDC

国内番号計画によって定義

SN

国内番号計画によって定義

最大 15 桁

図 14-1 には、次の定義が適用されます。

CC = 国番号

NSN = 国内の最上位番号

NDC = 国内の宛先コード

SN = 加入者数

ITU 勧告 E.164 に従って、電話番号の最大長は 15 桁です。地理的な E.164 番号の最初の部分は、国番号です。国番号の長さは、1 ~ 3 桁です(1 桁の国番号は、国番号 1 および 7 だけです)。地理的な E.164 番号の残りの部分は、国内の最上位番号(NSN)です。NSN の一般的な構造は、最初の数桁が国内の宛先コード(NDC)またはエリア コードを表し、最後の数桁が加入者数を表します。ITU 勧告 E.164 は国内番号計画を定義しないため、特定の国で NSN に使用するスキーマを規定していません。これは、国内番号計画の機関に任されます。次の URL で、さまざまな国別番号計画のドキュメントを入手できます。

http://www.itu.int/oth/T0202.aspx?parent=T0202

国内番号計画の構造は大きく異なります。例として、 表 14-2 で、米国とドイツで使用される番号計画を比較します。

 

表 14-2 米国とドイツの番号計画の比較

国コード
NSN 長
NDC 長
SN 長

1(米国)

10

3

7

49(ドイツ)

3 ~ 13

2 ~ 5

0(サービス番号)

4 ~ 11(通常の番号。エリア コードによって異なる)

ITU 勧告 E.164 には、国際プレフィックスが必要な場合、それを示すために先頭に「+」を使用する必要があることも記載されています。この設計ガイドでは、一貫して、「E.164」は E.164 番号を表し、「+E.164」は先頭に「+」が付いた E.164 番号を表します。

数値アドレスとして +E.164 番号を使用することには、これらの数値は本質的に一義的であり、企業のダイヤル プランでサポートする必要がある慣習的なダイヤリングと +E.164 のマッピングが非常に容易であるというメリットがあります。

一義的な数値の +E.164 アドレスを使用する代わりに、企業の番号計画に従って数値アドレスを使用することもできます。複数サイトの展開で企業アドレス計画または番号方式を確立するには、次の特性で一般的な階層型アドレス構造を定義します。

企業内のすべてのエンドポイント、ユーザ、アプリケーションに一義的な数値アドレスを提供します。

番号付け方式は、既存のエンドポイント、ユーザ、アプリケーションのアドレスの再割り当てなど、番号付け方式全体を再設計することなく新しいサイトを追加できるように拡張可能であることが必要です。

一般的な企業の番号計画では、数値アドレスはサイト コードとサイトの加入者番号で構成されます。企業の番号計画を設計するとき、サイトを必要に応じて追加でき、十分な加入者番号をサイトごとに定義できるようにするために、サイト コードとサイトの加入者番号の両方に十分な桁数を予約します。企業の番号計画は、通常は固定長で設計します。

企業の番号計画によって定義されるアドレスのダイヤリングをダイヤリング手順として直接サポートする必要がある場合、通常、1 桁のアクセス コードが選択され、会社の番号に前に付けられます。この場合、完全な会社の番号アドレスは、企業のアドレス アクセス コード(例:8)、サイト コード(例:496)、サイトの加入者番号(例:9123)の 3 つの部分で構成されます。この例では、8-496-9123 になります。

この場合、企業のアドレス アクセス コードは、他のダイヤリング手順とオーバーラップしないように選択する必要があります(「ダイヤリング手順」を参照してください)。

アドレス指定可能なエンティティを一義的に識別できるように、すべてのアドレスが一義的か、少なくとも呼処理エージェントが管理する定義済みサブ ドメイン内で一義的でなければなりません。同じアドレスを使用して 2 つの独立したエンティティをアドレス指定する必要がある場合、2 つの同一のアドレスは、個別に管理される分離したアドレッシング ドメインに存在しなければなりません。数値アドレスの場合、この状況はサイトの最上位数値アドレス(たとえば、4 桁の内線番号)を使用し、異なるサイトにあって同じサイトの最上位アドレス(同じ 4 桁の内線番号)を使用する 2 個のエンドポイントに、同じ呼制御エージェントでアドレス指定する必要がある場合に発生する可能性があります。 表 14-3 に、この状況の例を示します。

 

表 14-3 オーバーラップする数値アドレッシング

+E.164 番号
サイト(サブドメイン)
サイトの DID 範囲
4 桁の DN(アドレス)

+49 690 773 3001

フランクフルト

+49 690 773 3XXX

3001

+1 408 555 3001

サンフランシスコ

+1 408 555 3XXX

3001

表 14-3 で、2 つの E.164 番号が、それぞれのサイトの DID 範囲に基づいて、同じサイト固有の 4 桁のディレクトリ番号になります。これは、4 桁の DN を数値エンドポイント アドレスとして直接使用できないことを意味します。

英数字のアドレス

SIP URI に基づく英数字のアドレスも、エンドポイント、ユーザ、アプリケーションのアドレス指定に使用できます。英数字のアドレスに広く使用されている方式は、 ユーザ @ ホスト という簡略化された SIP URI で、左側(LHS、ユーザ部分)は英数字、右側(RHS、ホスト部分)はドメイン名です。次の例で、SIP URI に基づく有効な英数字のアドレスを示します。

bob@example.org

bob.home-office@example.org

bob@de.eu.example.org

bob.ex60@example.org

bob.vmbox@example.org

voicemail@de.eu.example.org

これらの URI はすべて、個々のエンドポイント、ユーザ、アプリケーションに対する個々の英数字のアドレスとして使用できます。アドレッシングの観点から見て、ドットで区切られた ID(bob.ex60、de.eu.example.org)の使用によって意味される階層が、任意の 2 つの URI が同等であると見なされるかどうかに影響を与えることはありません。

RFC 3261 に準拠して、SIP URI の LHS の比較は大文字と小文字を区別し、RHS は大文字と小文字を区別しないで比較しなければなりません。この標準化された動作に従い、Alice@example.com と alice@example.com は同等とは見なされず、その結果、別のアドレスを示します。実際には、ユーザ部分の大文字と小文字の区別に依存するエンドポイント、ユーザ、アプリケーションのアドレッシング方式を使用することは、トラブルシューティングが複雑になるため、望ましくないとされています。また、RFC 2543(RFC 3261 に先行する RFC 仕様)では、SIP URI(ホストおよびユーザ部分)は大文字と小文字を区別しないと明示的に定義されていることに注意してください。URI の等価性における大文字と小文字の区別に関して動作が異なることはよくあります。問題を回避するために、英数字のアドレスとしてすべて小文字の URI を常に使用することを推奨します。

Cisco Unified Communications Manager リリース 9.1 から、Unified CM の URI ルックアップ ポリシーは、大文字と小文字を区別する(デフォルト)か、区別しないかを設定できます。

ダイヤリング手順

ユーザ、エンドポイント、アプリケーションのアドレスのダイヤリングは、さまざまな形式を使用して行うことができます。数値の +E.164 アドレス +496907739001 は、たとえば、次のいずれかとしてダイヤルできます。

+496907739001

米国の内線から 9011496907739001

米国の固定電話から 011496907739001

ドイツの内線から 006907739001

イタリアの内線から 000496907739001

同じオフィスの電話から 9001

これらの例で、ダイヤルされたアドレスは通常、コンテキストで解釈され、+E.164 アドレスを直接ダイヤルする場合を除き、ダイヤルされたストリングとコンテキストの組み合わせだけが適切な ID を目的の宛先アドレスに提供することを示します。

「ダイヤリング手順」は、通常、特定の宛先のセットに到達するために使用される特定のダイヤリング動作を示します。いくつかの「ダイヤリング手順」の例を示します。

米国内から海外の宛先へのダイヤルは、9-0-1-1 に加え E.164

ドイツの国内通話は、0-0 に加え NSN

米国の国内通話は、9-1 に加え 10 桁

オフィスのサイト内コールは、4 桁

ダイヤリング手順は、ダイヤルされるストリングの形式(アドレス構造)と、到達する宛先アドレス クラスの両方を指定することで説明されます。通常、企業のダイヤル プランで使用される宛先アドレス クラスの例は次のとおりです。

オンネット/サイト内

オンネット/サイト間

オフネット/ローカル

オフネット/国内

オフネット/国際

サービス(ボイス メール、ピックアップなど)

英数字のダイヤリングでは、通常、完全修飾アドレスと非完全修飾アドレスだけを区別します。完全修飾アドレスには SIP URI のユーザ部分とホスト部分が含まれます。一方、英数字の非完全修飾アドレスはアドレスのユーザ部分だけを表し、ホスト部分は発信側のダイヤリング コンテキストから取得する必要があります。たとえば、発信側のダイヤリング コンテキストで、すべての英数字の非完全修飾アドレスに「@example.com」を追加する必要があると定義されている場合、「bob」とダイヤリングすることは「bob@example.com」とダイヤリングすることと同等です。

ダイヤル ドメイン

前のセクションで説明したように、ユーザごとに異なるストリングを使用して特定の宛先をダイヤリングできます。ダイヤル ドメインは、ダイヤリング手順の同じセットを共有する(同一の宛先に到達するために同じストリングをダイヤリングする)ユーザまたはデバイスのグループを指定します。企業のダイヤル プランでは、各ダイヤル ドメインで同じ処理を実装しなければならないため、ダイヤル ドメインの概念が重要です。特定のダイヤル ドメインに属するすべてのユーザが同じダイヤリング処理を共有します。

ダイヤル ドメインを特定するには、すべてのダイヤリング手順を考慮することが重要です。米国の 2 つのサイトのユーザが、同じ PSTN ダイヤリング手順を共有する場合でも、オンネット コールの実行方法を考慮すると異なるダイヤル ドメインに属する場合もあります。通常の環境では、オンネットのサイト内コールは 4 桁のダイヤルによってサポートされ、オンネット サイト間コールは PSTN のダイヤリング手順に対応するダイヤル ストリングを使用して実行されます(強制オンネットは、コールをオンネットのままにします)。

図 14-2 に、この例を示します。サイト SJC のエンドポイント 1234 とサイト RTP のエンドポイント 2001 が、国内の宛先(PSTN 宛先 +1 212 555 6000 に到達するために 91212555600 をダイヤル)と海外の宛先(PSTN 宛先 +49 890 123456 に到達するために 901149890123456 をダイヤル)で同じダイヤリング手順を共有する場合でも、サイト SJC のエンドポイント 1001 に到達するダイヤリング手順は RTP のエンドポイントと SJC のエンドポイントで異なります。サイト SJC のエンドポイント 1234 は 1001 をダイヤルし、サイト RTP のエンドポイント 2001 は 914085551001 をダイヤルする必要があります。この例では、サイト RTP とサイト SJC のエンドポイントは異なるダイヤル ドメインに属します。

図 14-2 ダイヤル ドメイン

 

サービス クラス(COS)

企業内のすべてのユーザ、アプリケーション、エンドポイントが同じ宛先のセットに到達できるわけではありません。到達可能な宛先のセットを制限する理由には、コストの回避、セキュリティ上の考慮事項、プライバシーなどがあります。たとえば、一部のユーザが国際通話を発信できない場合があります。ボイス メール システムは、不正通話を防止するために、PSTN 宛先にコールできない場合があります。非常に限られたユーザだけが、会社の CEO に直接コールすることが許可される場合があります。許可される宛先の制限またはクラスのセットを示すためによく使用される用語が、 サービス クラス 、または CoS です。

コスト重視のサービス クラスの要件は、関連付けられた電話料金とコスト構造に大きく依存します。音声サービスが安価になる(または無料で使用できるようになる)に従い、より多くのサービス クラスの管理に関連する複雑さの増大と、削減可能なコールのコストの間のトレード オフは変化しています。たとえば、市内通話と国内通話の両方のコール タイプの料金が完全に同じになり、区別する意味がなくなる場合があります。

サービス クラスの定義は、時間のスケジュールに基づく場合もあります。特定の宛先へのアクセスが、特定の時間にのみ許可される場合があります。

通常、コストが発生する特定のユーザ、デバイス、アプリケーションによる特定のコール タイプへのアクセスとは別に、緊急サービス(911、112 など)へのアクセスは常にすべてのユーザに提供されなければなりません。したがって、すべてのサービス クラスで緊急サービスへのアクセスを常に可能にしなければなりません。

コール ルーティング

コールのルーティングには複数の側面があります。

ダイヤルされるアドレスの構造に基づいてダイヤリング手順を特定します。

発信エンティティのサービス クラスに基づいてコールを許可/ブロックします。

ダイヤルされたアドレスに変更を適用します。

着信者 ID に変更を適用します。

着信先へのルートを選択し、コールを確立し、期待される形式で関連する ID を示します。ルート選択には、何らかの理由でプライマリ ルートが使用可能でない場合の、代替ルートの選択が含まれます。

エンドツーエンドの企業ダイヤル プランでは、これらの側面をすべて考慮する必要があり、発信側と着信側のエンティティ間でルートを確立することだけに限定されません。

ダイヤリング手順の特定と、オーバーラップの回避

発信エンティティからの入力を受信した後、コール ルーティング プロセスの最初の手順は、使用されるダイヤリング手順を一義的に特定することです。英数字のダイヤリングの場合、完全修飾 SIP URI と非完全修飾 SIP URI を区別するだけなので、これは通常、小さなタスクです。ダイヤルされたストリングの単純な文字分析によって容易に実現できます。

番号のダイヤリングの場合、特にダイヤルされる番号が 1 桁ずつ入力される場合は、少し注意が必要です。この場合、呼制御は発信エンティティから桁単位で宛先を受信し、十分な桁数を受信したときに、宛先への正しいルートを選択する部分を正確なタイミングで決定し、桁間のタイムアウトが発生するまで待たずにコールをルーティングする必要があります。

図 14-3 に、PSTN および緊急コール用の一般的な米国でのダイヤリング手順を示します。これらのダイヤリング手順のすべてで同一の先頭数字 9 を共有しますが、国際ダイヤルと最初の緊急ダイヤリング ストリングは、2 桁目(0 または 9)がダイヤルされるとすぐに、容易に区別できます。北米番号計画(NANP)では 1 で始まる NPA コード(番号計画エリア コード)が許可されていないために、3 番目の数字がダイヤルされるとすぐに、911 のダイヤリングと国内の宛先へのダイヤリングはオーバーラップしなくなります。

図 14-3 PSTN および緊急コール用の一般的な米国のダイヤリング手順

 

図 14-3 の PSTN のダイヤリング手順では、 9 で始まる内線への 4 桁のサイト内ダイヤリングは、部分的にオーバーラップする可能性があるため、回避する必要があります。たとえば、内線番号 9113 は緊急コールとオーバーラップし、呼制御は 911 を受信した後、発信者が 3 をダイヤルするか(内線 9113)、ダイヤリングが 911 で完了したかを判断しなければなりません。これは、すべての緊急コールを遅らせます。同様に、9140 などの内線は国内の PSTN コールとオーバーラップし、これらの内線番号へのコールは遅れます。

オーバーラップを最小限に抑えるには、ダイヤリング手順の 1 桁目は宛先クラスを一義的に識別するアクセス コードとして定義します。PSTN またはトランク アクセス コードはこの方式の最適な例です。最も一般的なトランク アクセス コードは 9(米国、英国など)および 0(欧州諸国のほとんどで一般的に使用)です。

前述のように、オーバーラップしないダイヤリング手順を選択することは桁間タイムアウトによるユーザ エクスペリエンスの低下を回避する鍵です。企業のダイヤル プランでよく見られるオーバーラップには、次のものがあります。

10 桁のダイヤリングと短縮サイト内ダイヤリング(たとえば、4 桁)

米国の NPA コードは 0 または 1 以外のあらゆる数字で始まる可能性があります。これは、10 桁のダイヤリングの最初の数桁が、ほとんどすべての短縮サイト内ダイヤリングとオーバーラップすることを意味します。

PSTN アクセス コード(米国の 9 など)と短縮サイト内ダイヤリング

PSTN アクセス コード 9 は、9 で始まる内線へのすべての短縮サイト内ダイヤリングとオーバーラップします。

短縮サイト内オンネット ダイヤリングと短縮サイト間ダイヤリング

企業の短縮オンネット番号計画用に選択されたアクセス コードが、同じ数字で始まるサイト間ダイヤリングの範囲とオーバーラップする可能性があります。たとえば、短縮オンネット サイト内ダイヤリングにアクセス コード 8 を使用した場合、8 で始まる短縮サイト内ダイヤリングを使用できなくなります。

コール パーク番号やボイス メールなどの機能へのアクセスも、定義されたダイヤリング手順のセットにマッピングする必要があります。これらの機能へのダイヤリングは、通常、短縮ダイヤル手順だけを必要とします。これを実現するには、機能アクセス コードを短縮サイト内ダイヤリングにマップするか、専用の機能アクセス コードを定義する必要があります。

強制オンネット ルーティング

オンネット/サイト間の宛先とオフネットの宛先へのダイヤリング手順で、同じアドレッシング構造を使用することは珍しくありません。この場合、呼制御が、アドレス指定されたエンドポイント、ユーザ、アプリケーションがオンネットかオフネットかをダイヤルされたアドレスに基づいて決定し、コールをそれぞれオンネットまたはオフネットとして扱います。

図 14-4 に、強制されたオンネット ルーティングの例を示します。この次の 4 つのコールは、91 プラス 10 桁としてダイヤルされます。ただし、+ 1 408 555 2345 と + 1 212 555 7000 へのコールは、実際にはオフネット コールとして PSTN ゲートウェイを介してルーティングされますが、他の 2 つのコールは呼制御がオンネット宛先として最終的な宛先を識別するため、オンネット コールとしてルーティングされます。強制オンネット ルーティングは、使用されるダイヤリング手順が必ずしもコールのルーティング方法を決定するわけではないことも明確に示します。この例で、使用された PSTN ダイヤリング手順でオフネットの宛先が呼び出されることが示されている場合でも、一部のコールはオンネット コールとしてルーティングされます。

図 14-4 強制オンネット ルーティング

 

強制オンネット ルーティングは、ディレクトリからの +E.164 宛先のダイヤリングが実装されている場合に、特に重要です。正規化されたディレクトリでは、番号に関連付けられているユーザが内部か外部かに関係なく、すべての宛先が +E.164 番号として定義されます。この場合、強制オンネット ルーティングは、PSTN を通じて内部コールをルーティングすることで発生する料金を回避するために必須です。

1 つの呼制御のコール ルーティング

すべてのエンドポイントが単一の呼制御に登録された場合、この呼制御がすべての既知のオンネット宛先を完全に認識できます。定義されたダイヤリング手順のいずれかを使用してユーザ、エンドポイント、またはアプリケーションが宛先をダイヤルしたときに、呼制御はダイヤルされた宛先がオンネットかオフネットかを容易に判断できます。これは、使用されたダイヤリング手順またはダイヤルされた正規化アドレスに基づきます(「強制オンネット ルーティング」を参照してください)。

ダイヤルされた宛先が外部だと判断されると、呼制御は、コールをセット アップするために正しい外部ルートを選択する必要があります。1 台の外部(PSTN)接続だけがある場合、これは簡単に決定できます。複数の外部接続がある場合は、次の要因を任意に組み合わせて出力ルートを選択できます。

コールの発信側

ダイヤルされた宛先

リソースの可用性

リソースの優先順位

ダイヤルされた宛先に基づいて外部接続を選べるように、ダイヤルされる宛先を分類する必要があります。前述したとおり、E.164 番号は番号が地理的な関係を意味する階層構造になっていて、出力接続の選択が宛先に(E.164 番号の地理的な意味で)「最も近い」出力ポイントを選択するプレフィックス ベースの階層型ルーティング スキームに基づきます。この動作はテールエンド ホップ オフ(TEHO)と呼ばれます。テールエンド ホップ オフを実装するときは、地域の規制を考慮しなければなりません。

市内電話(州内)より国内通話(州間など)のほうが低価格になる変わった通話料金では、TEHO の特別なケースが発生します。この場合は、ダイヤルされた宛先に「近すぎる」出力接続を実際には選択しないように、出力ポイント選択ポリシーを実装する必要が生じる場合があります。電話料金が下がれば、このようなルーティング スキームの有効性は低下します。

左側の英数字に最も重要な情報がある、明確に階層化された地理的な構造を持つ E.164 番号とは対照的に、SIP URI では、URI のホスト部分(RHS)でアドレスを階層化できます。RHS として使用されるドメイン名によっては、URI のアドレス階層は、特に user@example.org などのフラットな URI スキームが使用されている場合、必ずしも地理的なマッピングではありません。より興味深い点として、SIP URI の最も重要な要素は、ホスト部分の右端のデータです(トップ レベル ドメイン)。

複数の呼制御のコール ルーティング

大規模な企業ネットワークでは、多数の呼制御が導入されている場合があります。これらの独立した呼制御は、トランクを使用して相互に接続されます。可能なトポロジには、ハブ アンド スポーク、フル メッシュ、およびこれらの組み合わせがあります。これらの呼制御のいずれかが個別に、エンドポイント、ローカルに登録されたアプリケーション、または内部および外部トランクによって提供されたコールをルーティングします。

このような環境では、前のセクションで説明したオンネット/オフネットの決定が少し複雑になります。コールを外部接続にルーティングする前に、各呼制御が、ダイヤルされた宛先がほんとうにオフネットであることを確認する必要があります。しかし、ローカルに登録されたアドレスだけを確認しても、呼制御は、実際には信頼性の高いローカル/リモートの決定ができるだけで、リモート(ローカルに登録されていない)として分類された宛先が、導入されている他のエンタープライズ呼制御のいずれかでホストされている可能性があります。

個々の呼制御に数値アドレスを設定し、エンドポイントを厳密に地理的に割り当てて、特定の呼制御で正しい内部または外部接続を選択するには、E.164 プレフィックスに基づくルーティング方式を実装する必要があります。これは基本的に、プレフィックス ベースのルーティングに使用する接続の一部が外部接続(たとえば、PSTN への接続)ではなく、企業の他の呼制御エンティティへの内部接続であるという点を除いて、単一の呼制御の例で説明したコール ルーティング プロセスと同じです。リモート オンネットの宛先へのコールだけがリモート呼制御にルーティングされるようにするために、通常、他の呼制御に対してローカルな特定のアドレス範囲を使用して、コール ルーティングを定義する必要があります。

図 14-5 に、独立した呼制御間のプレフィックス ベースのルーティングをごく限定的にする必要がある理由を示します。この例では、左側の呼制御が 912125556001 をオンネット コールとして処理する必要があるかどうかを判断できるようにするために、左側の呼制御が、右側の呼制御エンティティによって提供されたすべての数値アドレスに対して特別な数字プレフィックス ルートを持っていなければなりません。

図 14-5 呼制御間のプレフィックス ベースのルーティング

 

英数字 URI の数値アドレスのプレフィックス ベース ルーティングは、ドメイン階層を使用して、URI のドメイン部分に基づいてルーティングを実行することと同じです。図 14-6 に、アルファベット URI を使用する階層型ルーティングの例を示します。この例では、階層的なドメイン構造に基づいてオンネット ルーティングを容易に実装できるように、3 個の独立した呼制御がすべて専用(サブ)ドメインを使用します。

図 14-6 アルファベット URI の階層型ルーティング

 

ダイヤル プランの要素

ここでは、次のソリューション コンポーネントで使用可能なダイヤル プラン要素について説明します。

「Cisco Unified Communications Manager」

「Cisco TelePresence Video Communication Server」

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 では、着信コールは + を番号の一部として発呼側番号として表示できます。コールが電話機に提供されたとき、呼び出し中の電話機に表示される番号は、設定された発呼側番号トランスフォーメーション パターンによって処理されます。不在コールと受信コールのディレクトリは、元の変換前の番号と変換された番号の両方を保持します。リストに表示される番号は変換された番号になり、変換前の番号はエントリの詳細を確認したときにだけ表示されます。ディレクトリからダイヤルされた番号は元の変換前の番号であり、発信番号の一部として + 記号が使用された以前の受信コールをワンタッチでダイヤルできるようになります。

例 14-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 がダイヤル プラン設定に基づいて電話機へ発行するコマンドです (図 14-7を参照)。

図 14-7 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 ダイヤル規則が設定されていない場合

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

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

 

ユーザが番号をダイヤルした後に [Dial] ソフトキーや # キーを押さなかった場合、電話機は桁間タイムアウト(デフォルトでは 15 秒)だけ待ってから、SIP INVITE メッセージを Unified CM に送信します。図 14-8 の例では、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 キーを押したり、桁間タイムアウトを待ったりする必要がありません (図 14-9 を参照)。

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

 

図 14-9 で、電話機は 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 を実行している電話機の操作モードと非常によく似ています (図 14-10 を参照)。

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

 

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

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

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

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

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

 

図 14-11 で、電話機は 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 ロジックを使用し、数字のコール ルーティング テーブルにあるすべてのパターンの中から一致パターンを選択します。一致する可能性のある数字パターンが複数ある場合は、次の基準に基づいて宛先パターンを選択します。

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

一致する可能性のあるパターンのうち、ダイヤルされたストリング以外に一致するパターンが最も少ないもの。

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

図 14-12 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 個しかありません(ダイヤルされたストリング)。したがって、このパターンがコールの宛先として選択されます。

可変長パターンの一致ストリングの数を判断する必要がある場合、Unified CM はダイヤルされた桁数と同じ長さの一致ストリングだけを考慮に入れます。次の表で、ユーザが 1311 とダイヤルし、パターン 1XXX、1[2-3]XX、13! がある場合に、パターンに一致するストリングの数と、一致する可能性があるストリングを示します。

 

パターン
一致するストリングの数
一致する可能性のあるストリング

1XXX

1000

1000 ~ 1999

1[2-3]XX

200

1200 ~ 1299、1300 ~ 1399

13!

100

1300 ~ 1399。ダイヤルされた桁数に基づいて、4 桁のストリングのみカウント

この例では、可変長パターン 13! が ベストマッチとして選択されます。


) Cisco Unified CM でディレクトリ番号(DN)を設定すると、それぞれのデバイス(IP Phone など)が登録済みかどうかにかかわらず、その番号はコール ルーティング テーブルに配置されます。この仕様によって、アプリケーション(およびそのプライマリ パターン)が未登録である場合は、セカンダリの一致パターンを利用してフェールオーバー機能をアプリケーションに提供することができなくなりました。プライマリ パターンがコール ルーティング テーブルに必ず存在するため、セカンダリ パターンに一致するかどうかは検索されません。


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

Unified CM 内のすべてのパターン(ルート パターン、トランスレーション パターン、ディレクトリ番号など)では、+ 記号を使用できます。+ を文字どおりの意味で使用するには、+ の前にエスケープ文字 \ を入力することで、先行文字の 1 つ以上のインスタンスを意味する正規表現演算子の + と区別します。次に、例を示します。

\+14085264000 は +14085264000 を意味します。

2+ は 2、22、222 などを意味します。

これによって、Unified CM の +E.164 ダイヤル プランのシームレスな実装が可能になります。

Directory URI

Unified CM に登録されているすべてのエンドポイントは、1 つ以上の数字(先頭に + が付く場合もある)を含むディレクトリ番号でプロビジョニングされます。最大 5 つの Directory URI を各ディレクトリ番号に関連付けることができます。この関連付けは、Directory URI をディレクトリ番号に明示的に関連付けることで作成できます。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 を提供できます。

Directory URI のクラスタ間ルーティングをイネーブルにするために、クラスタ間検索サービス(ILS)で他のクラスタと Directory URI カタログを交換するように Unified CM をプロビジョニングできます。他のクラスタと Directory URI カタログを交換するように設定された各クラスタは、ロケーション属性、SIP ルート ストリングとともに、すべてのローカルに設定された Directory URI を 1 つの Directory URI カタログでアドバタイズします。マルチ クラスタ環境では、Directory URI のホスト部分を使用して SIP 要求を確実にルーティングすることができない場合に、Directory URI へのコールを正しいクラスタに転送するために、このロケーション属性が使用されます。これは、たとえば、 <user>@example.com などのフラットな URI スキームを使用する場合です。ホスト部分の「example.com」は、この URI をホストするリモートの Unified CM クラスタを一義的に識別しません。

リモート クラスタから学習した Directory URI へのコールをルーティングする方法の詳細については、「Unified CM での SIP 要求のルーティング」の項を参照してください。

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

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

トランスレーション パターンは、図 14-13 の例に示すように、さまざまな用途に使用できます。

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

 

この例では、管理者は、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 ディレクトリには、常にユーザがダイヤルしたストリングがそのまま表示されます。


Unified CM の外部ルート

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

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

 

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

「ルート パターン」

「ルート リスト」

「ルート グループ」

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

ルート パターン

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

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

@ ワイルドカード

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

その他の国別番号計画を受け入れるように Unified CM を設定できます。この作業が完了すると、[Route Pattern] 設定ページの [Numbering Plan] フィールドで選択した値に応じて、同じ Unified CM クラスタ内で、複数の番号計画に対して @ ワイルドカードを使用できるようになります。詳細については、次の Web サイトで入手可能な『 Cisco Unified Communications Manager 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] チェックボックスをオンにします。ルート パターンには、PSTN アクセス コードだけを含める必要があります(北米では「9」、多くのヨーロッパ諸国では「0」)。

重複受信とは、ダイヤルされる番号を PRI PSTN ゲートウェイから Unified CM で 1 つずつ受信し、ストリングのダイヤルが完了するまで待機し、その後でコールを内部宛先にルーティングすることを意味します。重複受信を可能にするには、OverlapReceivingFlagForPRI サービス パラメータを True に設定します。

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

コールで最終的に利用するルート グループに関係なく、ルート パターンで設定する番号操作は、発呼側番号および着信側番号に影響を与えます。ルート リスト ビューにあるそのメンバーのルート グループに設定される番号操作が影響するのは、ルートに対してだけです。つまり、コールの発信に使用するルート グループに設定されている変換のみが実行されます。

ルート リスト ビューにあるそのルート グループの番号操作は、ルート パターンに設定される番号操作よりも優先されます。

ルート パターンやルート リストに設定される番号変換による発呼側番号および着信側番号は、選択したルート グループに含まれるデバイスに設定されているトランスフォーメーション パターンで処理されます。

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

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

発呼回線 ID

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

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

コールの分類

このルート パターンを使用しているコールは、オンネットまたはオフネットのコールとして分類できます。このルート パターンを使用すると、オフネット間でのコール転送を禁止したり、オンネット通話者がいない会議ブリッジを終了したりすることによって、料金詐欺を防止できます (これらの機能は、どちらも 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 トランクを参照するルート リストを直接ポイントすることができます。いっそうの柔軟性のために、フル 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 では、トップダウン アルゴリズムと循環アルゴリズムをサポートしています。

ルート グループ デバイス

ルート グループ デバイスは、ルート グループによってアクセスされるエンドポイントであり、一般に、ゲートキーパーまたはリモート 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 プロトコルを選択します。


ローカル ルート グループ

デバイス プールは、ローカル ルート グループに関連付けることができます。ローカル ルート グループを使用したルート パターンには、固有の特性があります。つまり、コールの発信元デバイスに基づいて出口ゲートウェイを動的に選択できます。それに対し、スタティック ルート グループを使用したルート パターンによってルーティングされるコールでは、コールの発信元デバイスに関係なく、コールが同じゲートウェイにルーティングされます。

例 14-2 ローカル ルート グループと非ローカル ルート グループの比較

図 14-15 では、9.1[2-9]XX[2-9]XXXXXX と定義されたルート パターンは、San Francisco ゲートウェイを含む非ローカル ルート グループを参照するルート リストを指しています。このルート パターンが Dallas、San Francisco、および New York の電話機のコーリング サーチ スペースに含まれているパーティションにある場合、それらの 3 つの都市にあるデバイスからの国内コールの出口は San Francisco の PSTN となります。

図 14-15 非ローカル ルート グループの動作

 

一方、図 14-16 に示すように、同じルート パターンを変更して、標準ローカル ルート グループを含むルート リストを指すようにした場合、Dallas サイトから発信されるコールの出口は Dallas ゲートウェイを経由した公衆網となり、New York サイトから発信されるコールの出口は New York ゲートウェイを経由した公衆網となり、San Francisco サイトから発信されるコールの出口は San Francisco ゲートウェイを経由した公衆網となります。

ローカル ルート グループを使用すると、すべてのサイトの電話機のコーリング サーチ スペースによって再利用が可能なサイトに依存しないルート パターンを使用して発信元デバイスに基づいて出力ゲートウェイを選択できます。

図 14-16 ローカル ルート グループの動作

 

デバイス モビリティ機能を使用すると、ローミングしている現在のサブネットに基づいて、デバイス プールをエンドポイントに割り当てることができます。これにより、電話機の現在のサイトに基づいた、ローカル ルート グループの割り当てが可能になります。

例 14-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 はプロバイダーによってスクリーニングされません。転送コールのローカル ルート グループの選択ポリシーを設定するサービス パラメータがあります。サービス パラメータは次のように設定できます。

Calling Party's Local Route Group :下位互換性のあるデフォルト。最初の発信者のデバイス プールに関連付けられたローカル ルート グループが選択されます(上の例では電話機 A)。

Original Called Party :着信側電話機のデバイス プールに関連付けられたローカル ルート グループが選択されます(上の例では電話機 B)。

Last Redirecting Party :PSTN にコールを転送している電話機のデバイス プールに関連付けられたローカル ルート グループが選択されます(上の例では電話機 B)。これらの最後の 2 通りの方法は、PSTN に最後に転送される前に、コールが複数のホップを介して転送される場合にのみ異なります。

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

中央ゲートウェイが設定されているシステムの場合、ローカル ルート グループによって、PSTN へのローカル フェールオーバーが簡素化されます。発信側サイトでゲートウェイへのローカル フェールオーバーが許可されているときに、単一のルート リストを使用することで、複数サイトの PSTN コールをルーティングできます。

例 14-4 中央ゲートウェイとローカル フェールオーバー

ある会社が、Chicago にあるトランクのグループに有利な PSTN 相互接続レートをネゴシエートするとします。ルート リストに、1 番めの項目として Chicago にあるゲートウェイを含むルート グループが含まれ、2 番めの項目として標準ローカル ルート グループが含まれている場合、処理されるコールは最初に Chicago にある低コストの推奨ゲートウェイに送信されます。Chicago ゲートウェイが使用可能でない、フリー ポートがない、あるいは発信側電話機と Chicago ゲートウェイ間で使用できる帯域幅が十分でない場合は、発信側電話機のデバイス プール設定でローカル ルート グループによって決定されている、2 番めの項目を使用して、発信側電話機と同じ場所にあるゲートウェイを経由したコールのルーティングが試行されます (図 14-17 を参照)。

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

 

緊急パターン

トランスレーション パターンとルート パターンは緊急パターンとして設定できます。緊急パターンのデフォルト値は、ルート パターンでは非緊急、トランスレーション パターンでは緊急です。ルート パターンおよびトランスレーション パターンの緊急パターンだけ設定できます。他のパターンは、すべて非緊急状態になります。

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

パターンを緊急にすると、設定済みのパターンがダイヤルされた番号とのベスト マッチになったとき、その直後に 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] を使用してコールをルーティングします。

9011! などの可変長緊急トランスレーション パターン (図 14-18 を参照)は、桁間のタイムアウトを強制しません。ダイヤルされた番号が受信され、分析されて、緊急トランスレーション パターンが唯一の一致になるとすぐに、トランスレーション パターンで定義された番号変換が実行され、トランスレーション パターンの CSS によって定義されるセカンダリ ルックアップがただちに実行されます。

図 14-18 緊急トランスレーションでの桁間タイムアウト

 

 

図 14-18 で示す設定がある場合、ユーザが 901133158405858 とダイヤルすると、コールは最後の数字がダイヤルされた直後にルーティングされます。コールはトランスレーション パターン 9011.! と一致し、ダイヤルされた番号は +3333158405858 に変換され(9011 が廃棄され、+ が前に付きます)、固定長の PSTN ルート パターン \+33XXXXXXXXX(フランスで使用される 9 桁の NSN)に一致します。

一方、ユーザが 9011496907739001 とダイヤルすると、桁間タイムアウトが発生します。9011.! に一致した後、 結果のディジット +496907739001 はルート パターン \+! に一致し、Unified CM は、発信者が以降の番号をダイヤルするつもりがないことを確認するために、次のディジットを待機する必要があります。以降にダイヤルされた番号も同じルート パターンに一致します。

図 14-18 では、緊急トランスレーション パターンを使用して短縮オフネット ダイヤリング手順を実装するいくつかの例も示します。8 で始まる両方のトランスレーション パターンが 8 桁をそのまま受け入れ、ダイヤルされた番号を +E.164 にトランスフォームし、セカンダリ ルックアップを実行します。

83315858 にダイヤリングすると、桁間タイムアウトなしで、すぐにルーティングされます。ダイヤルされた番号は固定長のトランスレーション パターン 8331.5XXX と一致し、変換された着信者番号 +33158405858 は固定長のルート パターン \+33XXXXXXXXX に一致します。

ただし、84969001 にダイヤリングしても、ただちにはルーティングされません。ダイヤルされた番号が固定長のトランスレーション パターン 8496.9XXX に一致し、変換された着信者番号 +496907739001 は可変長の PSTN ルート パターン \+! に一致します。この例は、中間トランスレーション パターン一致の緊急または固定長のパターン特性が、中間トランスレーション パターンに設定されている CSS によって定義されたセカンダリ ルックアップで継承されないことを示します。

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

発信側トランスフォーメーション パターンを使用すると、発番号のグローバル形式を、ゲートウェイ、トランクなどのルート グループ デバイスに接続されているオフクラスタ ネットワークで必要となるローカル形式に適応させることができます。

着信側トランスフォーメーション パターンを使用すると、着番号のグローバル形式を、ゲートウェイ、トランクなどのルート グループ デバイスに接続されているオフクラスタ ネットワークで必要となるローカル形式に適応させることができます。


) 着信側トランスフォーメーション パターンは、電話機に影響を与えません。また、デバイス プールの着信側トランスフォーメーション パターン CSS も、そのパターンが割り当てられている電話機に影響を与えません。


両方のトランスフォーメーション パターン タイプは、一致する発番号または着番号の数値表現で構成されます。使用される構文は、ルート パターン、トランスフォーメーション パターン、ディレクトリ番号などのその他パターンの構文と同じです (図 14-19を参照)。

変換演算子には、数字破棄命令(ドット前の番号など)、発信側トランスフォーメーション マスク、プレフィックス番号が含まれます。この演算子によって、発信側電話番号表示(Default、Allowed、または Restricted)が制御されます。発信側トランスフォーメーション パターンを設定することで、発信側の外部電話番号マスクを発番号として使用できます。

パーティションおよびコーリング サーチ スペースによって、どの発信側トランスフォーメーション パターンをどのゲートウェイまたはトランクに適用するかどうかが制御されます。ゲートウェイまたはトランクでは、関連するデバイス プールの発信側変換 CSS またはデバイス固有の発信側変換 CSS を優先順位の低い順に使用できます。同じメカニズムを使用して、着信側トランスフォーメーション パターンの適用を制御します。

[Call Routing Information] > [Outbound Calls] の [Gateway Configuration] ページで設定された発信側および着信側トランスフォーメーション パターンは、ゲートウェイに送信される発番号または着番号と、発信側または着信側の番号タイプおよび番号計画に影響します。[Incoming Calling Party Settings] で適用される発信側トランスフォーメーション パターンは、ゲートウェイから送信されるコールに適用されます。

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

 

図 14-19 は、発信側および着信側トランスフォーメーション パターンを、さまざまな 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 となります。

発信側トランスフォーメーション パターンをコールに適用するために使用するコーリング サーチ スペースを各番号タイプに設定できます。コーリング サーチ スペースには、発信側トランスフォーメーション パターンだけが存在するパーティションが保持される必要があります。これによって、厳密に番号タイプに基づくのではなく、発番号の構造に基づいた変更を発番号に適用できます。発信側トランスフォーメーション パターンでは、正規表現を使用して発番号が照合されます。複数の一致項目から選択するには、best-match プロセスが使用され、選択されたパターンの発信側変換がコールに適用されます。

着信の着呼側設定(ゲートウェイまたはトランク別)

前のセクションで説明されている、H.323 ゲートウェイとトランクの着信側の設定と同じで、着信の着呼側の変換も設定できます。これは、MGCP および SIP では使用できません。これらの着信の着呼側変換によって、コールを実際にルーティングする前に、着信の着呼側の情報を正規化できます。

Unified CM におけるコール特権

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

「パーティション」

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

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

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

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

 

パーティション

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

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

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

 


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


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

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

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

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

図 14-22 IP Phone の回線とデバイスのコーリング サーチ スペース(CCS)の連結

 


) デバイス モビリティを使用しない場合、デバイスのコーリング サーチ スペースは静的となり、デバイスをネットワークの別の場所に移動しても同じままです。デバイス モビリティを有効にした場合、電話機の IP アドレスによって決定されている、ネットワークで電話機が物理的に配置されている場所に基づいて、デバイスのコーリング サーチ スペースを動的に決定できます。詳細については、「デバイス モビリティ」を参照してください。


同じルート パターンが、2 つのパーティション(回線のコーリング サーチ スペースに含まれているパーティションとデバイスのコーリング サーチ スペースに含まれているパーティション)に指定されている場合、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 宛先として入力されている番号を検証します。

不在転送が電話機によってアクティブになっているときに、Forward All コーリング サーチ スペースを None に設定した場合にこの設定(Calling Search Space Activation Policy を With Activating Device/Line に設定)を使用すると、ディレクトリ番号のコーリング サーチ スペースとアクティブになっているデバイス コーリング サーチ スペースを使用することで、不在転送の試行を検証します。

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 での SIP 要求のルーティング

SIP トランクまたは SIP エンドポイントから受信した SIP 要求のルーティングは、特定のルールに従い、ローカルとクラスタ間の両方のルーティング要件が満たされます。図 14-23 に、Unified CM によるルーティング決定のフロー チャートを示します。最初の手順は、URI の左側(ユーザ部分)が、ディレクトリ番号と Directory URI のどちらかを確認することです。

図 14-23 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)を介してリモート システムから学習した Directory URI カタログで、再び完全一致によって SIP URI を探します。一致が見つかった場合、SIP 要求は、見つかった Directory URI に関連付けられた SIP ルート ストリングと設定済み SIP ルート パターンの一致によってルーティングされます。(図 14-24 を参照)。

SIP URI がローカル Directory URI で一致せず、どの Directory URI カタログ内の Directory URI ともマッチしない場合、Unified CM は SIP URI の右側のみと設定済み SIP ルート パターンとの一致に基づいて SIP 要求をルーティングします。この最終手段のルーティングは、ローカルや ILS を介して接続される他の呼制御サーバで不明なすべての SIP URI にデフォルト ルートを作成するのに使用できます。

図 14-24 Directory URI のルーティング例

 

図 14-24 に、ダイヤルされた Directory URI が Unified CM によってルーティングされる例を示します。この例では、下の Unified CM クラスタがローカル Directory URI「carol@cisco.com」をアドバタイズします。この Unified CM クラスタのすべてのローカル Directory URI は、SIP ルートストリング「fra.route」のもとにアドバタイズされます。ILS を介したこの情報交換の一部として、最上部の Unified CM クラスタは自身のローカル Directory URI カタログに「carol@cisco.com」から SIP ルートストリング「fra.route」への関連付けを読み込みました。最上部のクラスタに登録された電話機から Directory URI「carol@cisco.com」コールがなされた場合、Directory URI「carol@cisco.com」のローカル ルックアップは失敗します。「carol@cisco.com」はローカル Directory URI ではないからです。ルーティング プロセスの次のステップは、ILS が学習したテーブルで Directory URI「carol@cisco.com」を検索することです。この検索では、下部のクラスタから学習した情報を見つけることができ、最上部の発信元クラスタは学習した SIP ルーティング「fra.route」を使用し、SIP ルートストリング「fra.route」と設定済みルート パターンのマッチングでルートを探します。SIP ルート パターン「fra.route」が設定され、ルート リストをポイントします。ルートリストは最終的にはターゲット Unified CM クラスタをポイントする SIP トランクに到達します。発信元 Unified CM クラスタは、こうして宛先 Unified CM クラスタにコールをルーティングします。送信された SIP 要求の宛先は「carol@cisco.com」になります。宛先クラスタでは、図 14-23 に示したのと同じルーティング ロジックが、「carol@cisco.com」を宛先クラスタ上のすべてのローカル Directory URI とマッチングし、完全一致が見つかってターゲット デバイスが鳴ります。

上記の例は、SIP ルートストリングのネーム スペースが、Directory URI のネーム スペースから完全に独立していることを示します。Directory URI のホスト部分に使用するネーム スペースの構造と何らかの方法で関連する SIP ルートストリングを使用する必要はありません。これによって望ましいルーティング トポロジに基づいて SIP ルートストリングのネーム スペースを最適化することができます。直接 URI のホスト部分に一致する SIP ルート パターンと、SIP ルートストリングに基づいて Directory URI にルーティングするために使用される SIP ルート パターンを区別するために、SIP ルートストリング パターンに対して独立したネーム スペースを使用することを強く推奨します(「.route」、「.ils」など)。

上記の例では、基本的に、選択した SIP ルートストリングが個々の呼制御(fra.route、nyc.route)を識別し、学習した SIP ルートストリングに基づいて Directory URI SIP 要求のルーティングに使用される SIP ルート パターンのグリッドが、明示的なパターン(fra.route、nyc.route)を使用して目的の到達可能性を実現します。階層型トポロジでは、階層的な SIP ルートストリング(sjc.us.route、nyc.us.route、fra.de.route、muc.de.route など)を、Unified CM クラスタのセットにアドレスを指定するそれぞれの統合 Cisco Unified Communications Manager Session Management Edition(SME)クラスタにルーティングするワイルドカード SIP ルート パターン(*.de.route、*.us.route)とともに使用できます。

数値 URI のルーティング

SIP URI が数値 URI と見なされるのは、要求に user=phone タグが含まれている場合、または発信側デバイスの SIP プロファイルのダイヤル ストリング解釈設定に基づきます。コールは図 14-25 のフローチャートに従って処理されます。リリース 9.0 以前の Unified CM では、これが SIP 要求の標準ルーティング手順です。

図 14-25 数値 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 番めのコールをルーティングしようとします。

Cisco TelePresence Video Communication Server

この項では、Cisco TelePresence Video Communication Server(VCS)で利用可能なコール ルーティング メカニズムの概要を示します。詳細な説明については、次の URL にある『 Cisco TelePresence Video Communication Server Administrator Guide 』および各種 Cisco VCS の導入ガイドを参照してください。

http://www.cisco.com/en/US/products/ps11337/tsd_products_support_series_home.html

この項では、次の項目について説明します。

「Cisco VCS アドレッシング方式:SIP URI、H.323 ID、E.164 エイリアス」

「Cisco VCS アドレッシング ゾーン」

「Cisco VCS のパターン マッチング」

「Cisco VCS のルーティング プロセス」

Cisco VCS アドレッシング方式:SIP URI、H.323 ID、E.164 エイリアス

Cisco TelePresence Video Communication Server(VCS)は、H.323 と SIP を使用する通信を可能にし、本質的にこれらのプロトコルでサポートされているアドレッシング方式を可能にします。

ダイヤル可能なアドレスの形式は次のとおりです。

IPv4/IPv6 アドレス

IPv4 または IPv6 の IP アドレスを使用してエンドポイントとマルチポイント デバイスを呼び出すことができます。

H.323 ID

H.323 ID は H.323 エンドポイントの英数字の識別子です。任意の英数字のストリングを割り当てることができます。エンドポイントに SIP と H.323 の登録が必要な場合(デュアル登録)、このエイリアスは通常、SIP URI に一致します。

E.164 エイリアス(E.164 alias)

E.164 は PSTN と同じ番号設定方式を使用します。これは、H.323 ID とともに H.323(PSTN で使用される番号計画)で設定できるオプションです。

SIP URI

これは、常に ユーザ名 @ ドメイン の形式を取るエイリアスです。

ENUM

ENUM ダイヤリングでは、そのエンドポイントが異なる形式のエイリアスを使用して登録されていても、E.164 番号(電話番号)にダイヤリングした発信者がエンドポイントに接続できます。

基本的に、SIP URI は E.164 エイリアスを使用して作成できます。エイリアスのユーザ名部分は E.164 番号で、ホスト名部分がドメインになります。SIP を使用してこのタイプの E.164 マッピングを設定すると、エイリアスからユーザの情報が失われます。この場合、適切なエイリアス、 ユーザ名 @ ドメイン で FindMe を設定し、多くの異なるアドレッシング スキームから生じる複雑さを隠します。FindMe エイリアスはアドレッシング方式に関係なく、ダイヤル可能な任意のデバイスに関連付けることができます。

Cisco VCS アドレッシング ゾーン

VCS は、ローカルに登録されたエンドポイント、ネイバー システム、およびパブリック インターネットのエンドポイントからコールを受信します。

VCS に登録されているエンドポイント、ゲートウェイ、マルチポイント デバイス、およびコンテンツ サーバは、ローカル ゾーンの一部と見なされます。ローカル ゾーンはサブゾーンにさらに分割されます。デフォルトで存在するものも、管理者が設定するものもあります。

より一般的に言うと、ゾーンは同じダイヤリング動作と帯域幅の設定を共有するエンドポイントの集合です。ゾーンは VCS に対してローカルでもリモートでもかまいません。

ダイヤル可能なエンティティが VCS に登録されていない場合、他の呼制御またはシステムによって管理されるリモート ゾーンで使用可能な場合があります。これらのリモート ゾーンには、ネイバー ゾーン、トラバーサル クライアントおよびトラバーサル サーバ ゾーン、DNS ゾーン、および ENUM ゾーンがあります。

ネイバー ゾーンの概念は、Cisco Unified CM のトランクの概念と似ています。別の VCS、Unified CM サーバまたはクラスタ、サードパーティの呼制御システム、マルチポイント デバイス、またはゲートウェイへの SIP または H.323 トランク側接続です。

DNS ゾーンは DNS サービス(SRV)を使用して検出できるローカル以外の宛先です。トラバーサル クライアントおよびサーバは、VCS Control および VCS Expressway を使用してインターネット経由の通信にアクセスするためのゾーンです。ENUM ゾーンは、ENUM サービスを使用して到達できるローカル以外の宛先です。

Cisco VCS のパターン マッチング

VCS のルーティング ロジックの重要な概念が、トランスフォーム(検索前のトランスフォームとも呼ばれます)と検索ルール(検索とも呼ばれます)です。トランスフォームと検索の違いは、検索には宛先のターゲット ゾーンがありますが、トランスフォームはシステム レベルで設定され、単一ゾーンごとの適用ができないことです。

検索とトランスフォームは管理者が設定した優先順位に従って適用され、パターン分析とストリング操作に正規表現を使用します。

検索前のトランスフォームの概念は、Unified CM のトランスレーション パターンに似ていますが、正規表現を使用して英数字のトランスフォームができるという点が異なります。

検索ルールは、Unified CM のルート パターンに似ています。ルート パターンはトランクまたはルート リストに適用されますが、検索ルールにはターゲットとして宛先ゾーンがあります。

検索ルールとトランスフォームの両方に、次の主な特徴があります。

VCS がルールまたはトランスフォームの解析に使用する順番を定義する優先順位

ダイヤルされたパターンが検査される一致式(パターン ストリング)

宛先エイリアスの取得に使用される表現である、置換ストリング

正規表現で複雑なストリング操作が可能ですが、非常に一般的な、シンプルな適用例がいくつかあります。VCS の最も一般的なストリング操作の 1 つは、エイリアスのドメイン部分を追加するか削除することによって発生します。この例を示します。

エイリアス:88302

検索ルールの一致式(正規表現を使用):(\d+)

検索ルールの置換ストリング:\1@cisco.com

このシンプルなルールに従って、VCS に到達するダイヤルされたすべての番号が、number@domain に変換されます。この場合、88302 は 88302@cisco.com に変換されます。

サーチ ルールには、ダイヤリング方式の作成時に役立つ次の特性があります。

ターゲット ゾーン(必須)。ターゲット ゾーンは、VCS 内のコール用にローカル ゾーンにすることも、ネイバー、トラバーサル クライアントまたはサーバ、または DNS ゾーンとしてとして他のゾーンにすることもできます。ポリシー サーバが含まれる場合もあります。宛先ゾーンはユーザがダイヤルしたパターンに基づいて選択されます。

送信元ゾーン(オプション)。Cisco VCS リリース 7.2 から、特定のゾーンまたはサブゾーンから発信したエンドポイントにだけルールを適用することができます。

検索ルールに一致した場合の設定可能な動作(必須)。

VCS では、パターンに一致したエイリアスと、検出されたエイリアスおよびデバイスがコールに応答できるアドレスは異なります。

エイリアスが検索ルールの一致式に対して検査され、式がエイリアスと一致した場合、VCS は、そのエイリアスがターゲット ゾーンにあるかどうかを判断します。

検索ルールがエイリアスに一致し、エイリアスが検出された場合、コールはターゲット ゾーンに送信されます。

検索ルールがエイリアスに一致し、エイリアスが検出されない場合、ターゲット ゾーンにないことを意味します。この場合の VCS の動作は、検索ルールの [On Successful Match] フィールドの設定によって異なります。このフィールドが [stop] に設定されている場合、エイリアスが見つからなくてもルーティング エンジンは停止し、コールが宛先ゾーンに送信されます。フィールドが [continue] に設定されている場合、エイリアスが見つかるか、[On Successful Match] フィールドが [stop] に設定されているエイリアスにルールが一致するか、すべてのルールが分析されるまで検索プロセスは残りの優先順位が低いルールの分析を継続します。

この動作は、複数の呼制御プラットフォームに同じドメインを含む英数字 SIP URI が登録されているため、特定のエイリアスがある場所を管理者が知らない場合に役立ちます。たとえば、同じ企業内で複数の VCS が、同じドメイン company.com を共有する場合があります。user1@company.com へのコールは、宛先 VCS がわからない場合、正しくルーティングできません。ただし、VCS のルーティング ロジックを使用して、複数の VCS または他の呼制御システムでそのエイリアスを検索して、エイリアスが見つかったときにだけコールを送信することが可能です。

Cisco VCS のルーティング プロセス

Cisco VCS がコールを受信すると、設定された検索前のトランスフォームがすべて適用されます。検索前のトランスフォームの後、コール ポリシー ルーティング ロジック(CPL)が適用されます。このポリシーは、高度なルーティング ルール用の CPL スクリプトを使用して設定され、外部ポリシー サーバを含めることができます。ただし、大半のシナリオでは、CPL を使用する必要はありません。

FindMe エイリアスが設定されている場合、次にユーザ ポリシーが適用されます。FindMe ID は 1 つ以上のターゲット エイリアスに解決され、ターゲット エイリアスを正しく見つけるために、もう一度呼処理ロジックが開始されます。

VCS は、プライオリティの順に検索ルールを照会することで、エイリアスに一致する式を検索します。検索ルールが新しい宛先(SIP URI またはエイリアス)を返すと、プロセスが再開します。これは、コールが DNS サービス、ENUM サービス、またはポリシー サービスに送信される場合に発生することがあります。

エイリアスがいずれかのゾーン(ローカル ゾーン、ネイバーなど)で見つかるか、ルーティングの宛先がポリシー サービスによって返された場合、VCS はコールの発信を試行します。

一致がない場合は、コールが失敗したことを示すために、VCS はメッセージを返します。

ルーティング ロジックが最長一致に基づく Unified CM に対して、VCS では、ロジックは優先度ベースです。Unified CM でトランスレーション パターンまたはルート パターンの順序を変更しても、ルーティング アルゴリズムの結果は影響を受けませんが、VCS でルールの優先順位を変更すると、ルーティング動作が変わる原因になります。

推奨される設計

ここでは、設計指針と、エンドツーエンドの企業のダイヤル プランを実装する方法の概要を示します。

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] に設定する必要があります。

サービス パラメータ レベルの設定はグローバルな重要度を持つため、特別な変換のセットを使用しなければならないゲートウェイが 1 つだけ存在する場合は、デバイス プール レベルの設定を使用し、これらの設定が同じデバイス プールを共有するすべてのゲートウェイで共有されるようにするか、ゲートウェイのレベルの設定を使用することを強く推奨します。混乱を避けるために、特定のインストールではデバイス プール レベルの設定またはデバイス レベルの設定だけを常に使用し、混在させないことを推奨します(一部にはデバイス レベルの設定を使用し、残りにはデバイス プール レベルの設定を使用することは避けてください)。

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


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


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

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

論理パーティション

インドなどの一部の国には、企業外部でコールを接続するときに、企業の音声インフラストラクチャにローカル PSTN だけを使用することを義務付けた電気通信規制があります。このため、音声システムを 2 つのシステムに論理的にパーティション化する必要があります。2 つのシステムとは、企業内の非公開ユーザ グループ(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 つの各手順で、ローカル ダイヤリング手順のグローバルな記号として + を使用できます。

Unified CM のトランスレーション パターンはローカル化されたユーザ入力を電話機からダイヤルされたものとして、Unified Communications システム内のコールのルーティングに使用するグローバル形式に変換します。これらのパターンでは、ローカル化されたすべてのダイヤリング手順が認識されるようにする必要があります。これらの、トランスレーション パターンに基づくダイヤリングの正規化を実装する方法の詳細については、「グローバル化されたダイヤル プランのコール ルーティング」を参照してください。

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


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


電話機から発信されたコールの発信者番号は、コールの発信元回線のディレクトリ番号として設定されている番号に設定されます。グローバル化されたダイヤル プランのデザイン アプローチの概念に従って、すべてのコールの発信者情報をグローバル化する必要があります。ディレクトリ番号の形式がグローバル化された内部発信者情報用に選択された形式(通常は +E.164)と同じでない場合、着信コールの発信側変換 CSS(Unified CM 9.1 で、[Caller ID for Calls from this Phone] に名前が変更されました)を使用してディレクトリ番号を正しくグローバル化することで、発信者情報の適切な処理を実現する必要があります。これは、電話機から +E.164 へのコールの発呼側番号のグローバル化に推奨される方法です。この方法は、トランスレーション パターンが適用されない場合に URI でダイヤルされたコール フローの発呼側番号変換とも互換性があるからです。

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

外部ネットワーク(たとえば、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 番号と呼ばれることもあります。このマニュアルでは、この表記を +E.164(+ 記号が前に付く E.164)と示します。

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

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

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

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

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

たとえば、米国にいるユーザは、米国の発信者からの着信コールが、10 桁の国番号で表示され、+ 記号または国コード(1)がないものを好みます。グローバル電話番号が +1 408 555 1234 のユーザは、+1 408 526 4000 とコールすると、着信番号は、電話が鳴っている間、発番号として 408 555 1234 と表示されます。これを実現するために、システム管理者は発信側トランスフォーメーション パターンを \+1.!(ドットの前の番号を削除)と設定する必要があります。発信側トランスフォーメーション パターンは、宛先電話機の発信側トランスフォーメーション パターン 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 によって設定された着信側または発信側の番号タイプの表示を受信できません。


グローバル化されたダイヤル プランのコール ルーティング

ユーザ入力を認識するようにシステムを設定し、コールが正しい宛先にルーティングされ、送信されるようにします。コールはさまざまな形式で発信される可能性があるため、システムはそれらの各形式に一致するパターン認識を用意する必要があります。

グローバル化されたダイヤル プラン アプローチのコア ルーティングは、+E.164 パターンのルーティングに基づいているため、このダイヤル プラン アプローチのネイティブ ダイヤリング手順はグローバルな +E.164 ダイヤリングです。

Unified CM のトランスレーション パターンはローカル化されたユーザ入力を電話機からダイヤルされたものとして、Unified Communications システム内のコールのルーティングに使用するグローバル +E.164 形式に変換します。

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

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

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

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

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

図 14-26 で、米国のサンプル サイトのローカルなダイヤリング手順を使用してグローバル化された形式のダイヤリングをサポートする方法を示します。

図 14-26 ローカル化およびグローバル化されたダイヤリング

 

図 14-26 で、米国の IP Phone ユーザは 9011496100773 をダイヤルし、ドイツの宛先に接続してからコールを解除します。ドイツの着信側は米国のユーザにコール バックし、接続してから、コールを解除します。その後米国のユーザは Received コール ディレクトリに移り、最後の受信コールのエントリ(+49 6100 773)を選択し、Dial を押します。

この例では、米国のユーザは別々の 2 つのコールを同じ宛先(+496100773)に向けて開始します。最初のコールの場合、米国のダイヤリング手順に合わせてローカライズされた宛先番号の形式が使用されます。対応するトランスレーション パターン 9011.! に対して ユーザ入力がマッチングされます。変換されると、ルート パターン \+[^1]! がコールのルーティングに使用されます。2 つめのコールの場合、宛先番号のグローバル化された形式が使用され、ルート パターン \+[^1]! が直接使用されます。

これらのコール フローを比較すると、このダイヤル プラン アプローチで実装される 2 ステップのルーティング プロセスが明確に示されます。最初にすべてのダイヤリング手順を +E.164 に正規化し、+E.164 パターンに基づいてルーティングします。

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

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

これで、内線番号が +1 408 555 1234 であるユーザに、他のユーザからコーリング サーチ スペースを使用して到達できるようになります。この例では、次の番号をダイヤルします。

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

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

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

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

その他のサービス クラス

図 14-26 では、サービス クラス「national」の +E.164 ダイヤリング手順の正規化を作成するすべてのトランスレーション パターンで、着信側変換(+E.164 へのグローバル化)適用後にセカンダリ ルックアップのために使用される CSS が設定されます。

図 14-27 で、複数のサービス クラスでダイヤリングの正規化のトランスレーション パターンを再利用できない理由を示します。CSS SJCNationalWrong は CoS「national」を実装するもので、オンネット宛先および国内の PSTN 宛先だけにアクセスを許可する必要があります。明らかに、緊急番号へのアクセスも利用できる必要があります。これについては、「緊急コール」の項で説明します。

図 14-27 ダイヤリングの正規化の再利用による問題

 

図 14-27 からわかるように、CSS SJCNationalWrong はパーティション PSTNInternational の国際 PSTN ルート パターンにアクセスできませんが、サービス クラス「international」用に定義されているダイヤリングの正規化のトランスレーション パターンがあるパーティション UStoE164International を再利用することで、バック ドアが開きます。CSS SJCNationalWrong を使用すると、実際にはユーザが 9011498905551234 をダイヤルしてドイツのオフネット国際 PSTN 宛先に到達できるようになります。図 14-27 の赤い矢印は、このコールがルーティングされる方法を示します。ダイヤリングの正規化のトランスレーション パターン 9011.! に一致すると、変換された発信側番号 +498905551234 はその正規化のトランスレーション パターンで定義された CSS USE164International を使用してルーティングされます。CSS USE164International は、最終的に、国際 PSTN ルート パターン \+[^1]! で、パーティション PSTNInternational へのアクセスを付与します。

図 14-28 に、サービス クラス「national」を正しく実装する方法を示し、図 14-26 で示したサービス クラス「international」との違いを赤色の網掛けで示します。このスキーマを図 14-26 のサービス クラス「international」と比較すると、パーティション E164OnNet、SJCIntra、SJCtoE164local、USPSTNNational および SJCPSTNLocal が、コーリング サーチ スペース DN および SJCE164Local と同様に再利用できることがわかります。USToE164National のダイヤリングの正規化は、図 14-27 で示す問題を回避するために作り直されなければなりません。

図 14-28 サービス クラスごとのダイヤリングの正規化のレプリケーション

 

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

図 14-29 は、サービス クラス「local」が、サービス クラス「national」に基づき、国内 PSTN ルート パターンへのアクセスを削除し、必要なダイヤリングの正規化を複製することによって構築されることを示しています。この場合、既存のコーリング サーチ スペース SJCE164local がすでに適切なパターンへのアクセスを提供しており、これを再利用できるため、ダイヤリングの正規化のトランスレーション パターンは、サービス クラスに固有のセカンダリ ルックアップ コーリング サーチ スペースを必要としません。

図 14-29 サービス クラス「local」

 

最後の例として、図 14-30 に、サービス クラス「internal」を実装するコーリング サーチ スペースを示します。

図 14-30 サービス クラス「internal」

 

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

オンネット コールの桁間タイムアウトの回避

パーティション E164OnNet は、すべてのオンネット宛先の +E.164 プレフィックスに一致する緊急トランスレーション パターンを保持します。DID 範囲が + 1 408 555 1 XXX のサイトでは、E164OnNet に緊急トランスレーション パターン \+14085551XXX が存在します。これらのトランスレーション パターンの目的は、次の 2 つです。

まず、+E.164 からディレクトリ番号の形式にマップします。たとえば、DID 範囲が + 1 408 555 1XXX のサイトでディレクトリ番号は E.164(プラスなし)として設定され、トランスレーション パターン \+.14085551XXX と着信側変換の「ドットの前の番号を削除」(プラスを削除)を E164OnNet で設定する必要があります。また、SJCIntra のサイト内ダイヤリングのトランスレーション パターンは、+1408555 の代わりに 1408555 を先頭に付加するように変更する必要があります。

+E.164 としてディレクトリ番号を設定することを強く推奨しますが、ディレクトリ番号は E.164(プラスなし)などの別のグローバル化形式、簡潔な企業の番号付けスキーム、または米国の 10 桁で設定することもできます。+E.164 としてディレクトリ番号を設定しない場合、グローバル化された発信者 ID 用に、追加の番号の正規化を設定する必要があります。また、一部の CTI アプリケーション(たとえば、アテンダント コンソール アプリケーション)では、設定されているディレクトリ番号がグローバル ディレクトリに格納されている形式と一致しない場合、追加の番号の正規化が必要になる場合があります。

E164OnNet の緊急トランスレーション パターンの 2 番目の目的は、図 14-31 に示すように、+E.164 ディレクトリ番号と可変長 PSTN ルート パターンの間で桁間タイムアウトが発生する原因となる部分的なオーバーラップを避けることです。

図 14-31 +E.164 DN と可変長 PSTN ルート パターン間のオーバーラップ

 

図 14-31 に、この章で使用したサイト SJC の CoS International の CSS 実装の簡易バージョンを示します。この簡易バージョンでは、パーティション E164OnNet が取り除かれ、CSS SJCInternational は直接 +E.164 ディレクトリ番号を含むパーティションを使用しています。

ユーザが +496907735001 をダイヤルした場合、これは DN のパーティションの +E.164 ディレクトリ番号と完全一致しますが、すぐにはコールがルーティングされません。オーバーラップが可変長 PSTN ルート パターン \+[^1]! と パーティション PSTNInternational の間に発生し、ディレクトリ番号は非緊急であるためです(「緊急パターン」を参照してください)。

図 14-26 のパーティション E164OnNet の緊急トランスレーション パターンは、既知のオンネット宛先がダイヤルされるとすぐに即時の一致を作成します。これによって、桁間タイムアウトを発生させずに、オンネット宛先を +E.164 番号としてダイヤルできます。

+E.164 オンネット宛先と可変長ルート パターン(通常は PSTN ルート パターン)の間にオーバーラップの可能性がある場合にのみ、パーティション E164OnNet およびすべてのオンネット +E.164 プレフィックスに一致する緊急トランスレーション パターンが必要です。たとえば、すべての +E.164 オンネット宛先が米国ベース(+1 プラス 10 桁)の場合、唯一の可変長ルート パターンは明示的に 1 以外の数字で開始する +E.164 プレフィックスとだけ一致するため、上の図で示す PSTN ルート パターンを使用するとオーバーラップが発生しません。

オンネット +E.164 プレフィックスと可変長 PSTN ルート パターン間のオーバーラップがない導入では、パーティション E164OnNet を介して実装される中間変換手順は必要ありません。

緊急コール

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

通常、推奨される方式は、発信側デバイスの物理的な場所にローカルな緊急番号で、緊急コール サービスを提供することです。これによって緊急番号と他のダイヤリング手順との間でオーバーラップが発生する場合がありますが(たとえば、短縮ダイヤリングが 9XXX のサイトから米国の電話機にログインした米国以外のユーザのための 9 で始まる 4 桁のサイト内ダイヤリングと、911)、少なくとも、指定された場所の電話機は、いつでも、別の緊急番号を使用する地域のリモート ユーザがログインしているかどうかに依存せずに、現地の慣習的な緊急ダイヤリングを使用して緊急コールを発信できることが保証されます。

この動作を実装するには、緊急パターンをデバイス コーリング サーチ スペースで処理できる必要があります。

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

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

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

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

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

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

Call Forward Unregistered(CFUR)

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

Cisco Jabber などのソフト クライアントからの E.164 番号のクリックツーダイヤル

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

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

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

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

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


) AAR をイネーブルにするには、着信側ディレクトリ番号がグローバル化された形式ですでに設定されている場合でも、着信先で AAR マスクまたは外部電話番号マスクをグローバル化された形式で設定する必要があります。AAR は AAR マスクまたは外部電話のマスクが設定されている場合にだけアクティブになります。


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

Cisco Emergency Responder

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

どちらの Emergency Responder サーバも利用できない場合、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 番めのエントリとして標準ローカル ルート グループを指すように設定することによって実現できます。

Unified Communications Manager と TelePresence Video Communication Server の統合

Cisco Unified Communications Manager(Cisco Unified CM)は、Cisco TelePresence System C シリーズ、EX シリーズ、Profile シリーズ、SX シリーズのコーデック登録および英数字 URI ダイヤリングをサポートします。このシナリオで、Cisco TelePresence Video Communication Server(VCS)は、2 個の主要な機能を実行できます。

ビデオおよびコンテンツの H.323 と SIP の相互運用性

VCS Control および VCS Expressway を使用した Business-to-Business(B2B)アクセス

H.323 レガシー エンドポイントを VCS に登録でき、これにより、H.323/H.239 と SIP Binary Flow Control Protocol(BFCP)との間のプロトコル変換とコンテンツの相互運用性を実現します。このシナリオで、VCS はシグナリングおよびメディア ゲートウェイとして機能し、メディアを処理する必要もあるため、インターワーキング機能をオンにしなければならないことに注意してください。

VCS に接続されている H.323 エンドポイントは、Unified CM と同じ番号計画を共有します。

エイリアスの操作および正規化は、標準ベースの Portable Operating System Interface for Unix(POSIX)形式の正規表現構文を使用して VCS で行われます。POSIX は、オペレーティング システム(UNIX)がサポートする必要がある照合および置換機能のいくつかを定義する標準の集合です。

図 14-32 に、Unified CM と VCS に登録された音声およびビデオ エンドポイント間のエンドツーエンド通信、および VCS Expressway による企業の外部のピアとの通信を可能にする Cisco VSC と Unified CM の相互接続のトポロジ例を示します。

図 14-32 Cisco VCS と Unified CM を相互接続するためのサンプル トポロジ

 

+E.164 番号計画

Unified CM と VCS との間でグローバル化されたコール ルーティングを可能にするには、「Unified CM のグローバル化されたダイヤル プラン アプローチ」の項で説明したグローバル化されたダイヤル プランを Unified CM で実装し、+E.164 アドレスを VCS にプロビジョニングする必要があります。また、VCS に登録された各エンドポイントの H.323 ID が、+E164 番号とともに設定され、ローカル ゾーンに登録されなければなりません。

エイリアスの正規化と操作

エイリアスの正規化の目的は、エンドポイントをダイヤリングするときに、正しいエイリアスを示すことです。エイリアスの正規化は、システム レベルまたはゾーン レベルで発生する可能性があります。

システム レベルの正規化の例は、H.323 エンドポイントと SIP エンドポイントが VCS に登録されている混在環境でダイヤル プランの透過性を実装するときに発生します。H.323 エンドポイントは、VCS のローカル ゾーンに H.323 ID と E.164 エイリアスを登録します。ただし、SIP エンドポイントが E.164 エイリアスをダイヤルすると、ユーザが E.164 番号をダイヤルしただけでも、自動的にドメインが追加されます。E.164 番号が相手側の VCS にとってローカルまたはリモートのいずれであっても、正規化ルールによってコールの転送前に、ドメインが削除されます。これは、トランスフォームを使用して行うことができます。

ゾーン レベルの正規化の例は VCS を Unified CM クラスタに接続したときに発生します。この場合、Unified CM が、登録されているエンドポイントのエイリアスに一致しないエイリアス形式を使用している可能性があります。これは、Unified CM から受信したコールでだけ発生するため、宛先への転送前に検索ルールを適用して、エイリアスを標準化できます。

正規化後に、操作も発生する可能性があります。コールが VCS のエイリアス形式をサポートしない非 VCS システムに送信される際に、正規化の後で操作が発生する可能性があります。

次の例で、H.323 エンドポイント接続および B2B 接続に使用される VCS クラスタに接続された Unified CM クラスタについて考えます(図 14-32 を参照してください)。

この場合、エイリアスの正規化は必要ありません。すべてのエンドポイントは +E164 エイリアスと同じ H.323 ID で到達可能です。ただし、Unified CM との間で送受信されるコールは、最終的な宛先にルーティングされる前に操作を必要とします。

H.323 エンドポイントが VCS に登録されている別の H.323 エンドポイントをコールするとき、H.323 ID と同じに設定されている +E.164 番号を使用し(図 14-32 の +14085551001)、コールは正しく発信されます。

ただし、コールが Unified CM に送られるときは、SIP-to-H.323 インターワーキングが発生し、結果としてドメインを追加する検索ルールが必要になります。範囲 +14085551XXX の +E.164 番号がローカル VCS で使用されていると仮定すると、例 14-5 の検索ルールが必要です。

例 14-5 VCS のローカル +E.164 宛先用の検索ルール

Search Rule "To VCS"
Description: To Local +E164
Priority: 50
mode: alias pattern match
pattern type: regex
pattern string: (\+14085551\d{3})(@.*)
pattern behavior: replace string: \1
On successful Match: Stop
Target: Local Zone

内部の範囲をダイヤルする VCS に登録された各 H.323 クライアントは、このルールに一致します。

+E.164 コールが Unified CM から VCS に着信した場合、ダイヤルされたアドレスは次のいずれかの形式になります。

+14085551XXX@10.10.10.10:5060(@ に続いて VCS の IP アドレスとポート番号。ポート番号は 5060 か、Unified CM のトランク設定でピアとして VCS の IP アドレスを使用する場合は 5061)

+14085551XXX@vcs1.cisco.com:5060(@ に続いて VCS の DNS 名とポート番号。ポート番号は 5060 か、Unified CM のトランク設定で VCS の DNS 名を使用する場合は 5061)

+14085551XXX@cisco.com:5060(@ に続いてドメインとポート番号。ポート番号は 5060 か、Unified CM のトランク設定でドメイン名と DNS SRV レコードを使用する場合は 5061)

Unified CM から VCS へのトランクを設定する推奨される方法は、Unified CM の IP アドレスを使用して、VCS をピアとして定義する方法です。

例 14-5 のパターン ストリング (\+14085551\d{3})(@.*) は、上の 3 つの形式のすべてと一致し、定義された置換ストリングで受信した SIP URI の右側が削除されます。これによって、受信した +E.164 アドレスは VCS で設定された H.323 ID と正しく一致するようになります。

より優れたパターン選択が必要な場合には、より厳しいパターン マッチングを使用することが可能です。たとえば、([^@]*)@(%ip%|[^@]*cisco.com(.*)) を使用します。このパターンは、@ を含まれない文字シーケンスで始まり、@ と、VCS クラスタの VCS ピアの IP アドレスまたは「cisco.com」とポート番号を含む文字列が続くすべての URI と一致します。

いくつかの SIP エンドポイントが VCS に登録されている場合、自動的にドメインが追加されます。この場合も、上記の検索ルールでドメインが削除されます。

VCS から Unified CM にルーティングされる数字の +E.164 コールの場合、H.323 エンドポイントが自動的にドメインを追加しないため、発信要求の SIP URI にドメインを追加しなければなりません。Unified CM に送信されるコールのドメインを追加するために、例 14-6 に示すような検索ルールを作成しなければなりません。

例 14-6 検索ルール「To UCM」

Search Rule "To UCM"
Description: To UCM +E164
Priority: 100
mode: alias pattern match
pattern type: regex
pattern string: (\+14085551\d{3})(.*)
pattern behavior: replace string: \1@cisco.com
On successful Match: Stop
Target: UCM Zone

例 14-6 の検索ルールによって、\+14085551XXX に一致し、ローカル クライアントに一致しない VCS からのすべての数字のダイヤリングが Unified CM に送信され、Unified CM に送信される SIP URI のホスト部分が「cisco.com」に設定されます。「Unified CM での SIP 要求のルーティング」の項、特に図 14-25 に記載されているように、Unified CM が Unified CM で設定された番号の +E.164 ダイヤル プランに従ってこれらの数字の SIP URI のパスをルーティングできるように、Unified CM の SIP ルーティング メカニズムに従って、Unified CM の組織のトップ レベル ドメイン(OTLD)は「cisco.com」に設定されていなければなりません。このルールは、VCS に登録された SIP エンドポイントがある場合、これにも一致します。

B2B 接続を可能にするには、VCS が、B2B 構築ブロックにローカル以外の SIP URI のホスト部分があることで識別されるすべての B2B コールを VCS Expressway にルーティングしなければなりません。例 14-7 の検索ルールは、cisco.com 以外のドメインを持つものすべてに一致し、一致したものを VCS Expressway およびインターネットへ送信することによって、これを実現します。

例 14-7 B2B の検索ルール

Search Rule "External"
Description: for B2B
Priority: 110
mode: alias pattern match
pattern type: regex
pattern string: [^@]*@[^@]*(?<!cisco.com)
pattern behavior: leave
On successful Match: Stop
Target: VCS-E

Unified CM で、VCS でホストされる +E.164 プレフィックスは、特定の +E.164 ルート パターンを Unified CM ダイヤル プランに追加し、適切なルート リストおよびルート グループ設定によってこのルート パターンが VCS へのトランクに対応することを確認することによって、追加されなければなりません。

VCS に登録されたエンドポイントが Unified CM に登録されたエンドポイントと同じ DN 範囲を共有している場合、Unified CM のダイヤル プラン設定は、Unified CM で不明であるローカル プレフィックスのすべての +E.164 番号が VCS にルーティングされることを保証しなければなりません。図 14-33 に、グローバル化されたダイヤル プラン アプローチでこれを実現する方法を示します。

図 14-33 未割り当てのディレクトリ番号の代行受信

 

図 14-33 のグローバル化されたダイヤル プランは、「Unified CM のグローバル化されたダイヤル プラン アプローチ」の項で説明したアプローチを使用します。端的に言えば、既知のオンネット +E.164 プレフィックスで一致する、すべてのダイヤリングの正規化のトランスレーション パターンおよび緊急トランスレーション パターンから参照される DN コーリング サーチ スペースは、VCS と共有する +E.164 プレフィックスで一致するルート パターンを含むように拡張しなければなりません。Unified CM のディレクトリ番号と一致しなかったこの範囲のすべての +E.164 パターンは、このルート パターンに一致し、VCS に送信されます。ルーティング ループが発生しないように、VCS から着信するトランクのインバウンド コーリング サーチ スペースは、このルート パターンにアクセスして戻らないようにしてください。

また、Unified CM のダイヤル プランは、Unified CM にとってローカルな Directory URI に対応しない、URI(数字でない)としてダイヤルされたすべてのコールが VCS にルーティングされるようにする必要があります。これを実現する最も簡単な方法は、Unified CM で、適切なルート リストおよびルート グループ設定を通じて VCS へのトランクにも対応する「catch-all」SIP ルート パターン(*.* など)を追加することです。ここでも、ルーティング ループが発生しないように、VCS から着信するトランクのインバウンド コーリング サーチ スペースは、この「catch-all」SIP ルート パターンにアクセスしないようにしてください。

エンドポイント SIP URI の実装

Unified CM のエンドポイントに SIP URI および +E164 番号を使用して到達できる場合、例 14-8 に示すように、VCS から Unified CM に正しくルーティングする別の検索ルールを追加できます。

例 14-8 VCS から Unified CM への URI ダイヤリングの検索ルール

Search Rule "URI To UCM"
Description: SIP URI to UCM
Priority: 100
mode: alias pattern match
pattern type: suffix
pattern string: cisco.com
pattern behavior: leave
On successful Match: Stop
Target: UCM Zone

H.323 エンドポイントが、+E.164 エイリアスを使用する代わりに同じ SIP URI 形式の英数字のエイリアスを使用してアドレス指定されている場合、例 14-5 の「To VCS」検索ルールは、例 14-9 のいずれかに置き換えることができます。

例 14-9 H.323 登録エンドポイントの URI ダイヤリングをサポートするように変更された検索ルール「To VCS」

Search Rule "To VCS"
Description: To Local H.323 aliases
Priority: 50
mode: alias pattern match
pattern type: suffix
pattern string: cisco.com
pattern behavior: leave
On successful Match: Continue
Target: Local Zone

エイリアスがローカル ゾーンにない場合、これはエイリアスではなくローカルであることを意味し、優先度 100 の次のルール(「To CUCM」)に従って Unified CM に送信されるため、「Continue」をイネーブルにしなければなりません。ただし、コールが Unified CM から送信された場合は、コールの発信元である CUCM ゾーンに戻されないため、ルーティング ループが防止されます。

Unified CM で、+E.164 が VCS にルーティングするために使用する同じルート リストを指す「cisco.com」に一致する SIP ルート パターンを作成しなければなりません。

Unified CM のユーザが alice@cisco.com をダイヤルすると、Unified CM は最初に、ローカルに設定された SIP URI とこの URI を照合し、次にフォール バックとして、設定された SIP ルート パターンとホスト部分(cisco.com)を照合し、上記の SIP ルート パターンが一致して、コールは VCS ルーティングされます。VCS で URI がわかっている場合は、コールがエンドポイントにルーティングされますが、URI が未知である場合、コールはそのゾーンから送信され、操作されていないため、Unified CM に戻されません。

特記事項

この項では、次のような多くの Cisco Unified CM の機能に関連する、ダイヤル プランに関する考慮事項を説明します。

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

「デバイス モビリティ」

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

「時間帯ルーティング」

「論理パーティション」

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 グループを設定する必要のない +E.164 ダイヤル プランのメリットがはっきりとわかります。

ボイスメールの考慮事項

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 コーリング サーチ スペースを動的に決定できます。詳細については、「デバイス モビリティ」を参照してください。


デバイス モビリティ

デバイス モビリティには、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 機能と組み合わせる場合は、一定の制限事項があります。図 14-34 に示した例について考えます。エクステンション モビリティと AAR を集中型呼処理の Unified CM クラスタに配置していて、San Jose と New York にそれぞれ 1 つのサイトがあります。

図 14-34 エクステンション モビリティと 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 のリモート宛先プロファイルに関連付けられた再ルーティング コーリング サーチ スペースによって処理されます。


リモート宛先プロファイルのコーリング サーチ スペース

新しいサービス パラメータ(Inbound Calling Search Space for Remote Destination)が、クラスタのリモート宛先のいずれかから発信されたコールのルーティングに使用されるコーリング サーチ スペースを制御します。デフォルト設定は Trunk or Gateway Inbound Calling Search Space です。これはすべての着信コールをトランクまたはゲートウェイの設定済み CSS を使用してルーティングします。サービス パラメータが Remote Destination Profile + Line Calling Search Space に設定されると、コールをルーティングするために、一致したリモート宛先に関連付けられた DN の回線 CSS と、リモート宛先に関連付けられたリモート接続先プロファイルの CSS を連結したものが使用されます。

同じクラスタ内のリモート宛先として定義されているすべての番号は、クラスタに着信する任意の外部コールで一致するものを検索します。

次の例では、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 コール リストからワンタッチ ダイヤルを使用した方法を示しています。


) リモート宛先番号をパーティションに分類する方法はありません。複数のユーザ グループ(異なる会社、請負業者など)で同じクラスタを使用している場合、この点に注意する必要があります。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 にコールをルーティングできる)は好ましくありません。外部パターンとオンネット パターンが重複する状況が発生する可能性があるためです。


時間帯ルーティング

この機能を使用するには、次の要素を設定します。

期間

タイム スケジュール

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

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

図 14-35 では、同じコール パターン(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 日は非アクティブです。

図 14-35 時間帯ルーティング

 

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

論理パーティション

論理パーティションには、次の要素が含まれます。

デバイス タイプ。電話機は interior として分類され、ゲートウェイとトランクは border として定義されます。 表 14-4 に、各デバイスのエンドポイント タイプを示します。

ジオロケーション。エンドポイントにはポリシーの決定に使用される住所が割り当てられます。

ジオロケーション フィルタ。ポリシーの決定は、ジオロケーション オブジェクトのサブセットに対して行うことができます。

ポリシー。エンドポイント間の通信は、それらの相対的な(フィルタ処理された)ジオロケーションとデバイス タイプに基づいて許可または拒否されます。


) コールのすべての参加者が interior として分類されないと、ポリシーは適用されません。つまり、同じクラスタにある電話機間のコールに論理パーティション ポリシーが適用されることはありません。



) ジオロケーションは、Unified CM で設定するコール アドミッション制御用のロケーションや、デバイス モビリティに使用される物理ロケーションと混同しないでください。


 

表 14-4 デバイス タイプ

論理パーティションのデバイス タイプ
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 デバイスに接続できるように明示的にポリシーを設定していない限り、コール レッグは拒否されます。