この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
ダイヤル プランは、ユニファイド コミュニケーションおよびコラボレーション システムの重要な要素の 1 つであり、すべての呼処理エージェントにとって不可欠となる部分です。概説すると、ダイヤル プランは、コールをどのようにルーティングするかを呼処理エージェントに指示する役割を果たします。具体的には、ダイヤル プランは次の機能を実行します。
呼処理エージェントに登録された宛先に、到達可能性を実現するためにアドレスが割り当てられます。これらの内部の宛先には、すべてのエンドポイント(IP Phone、ビデオ エンドポイント、ソフト クライアント、アナログ エンドポイントなど)とアプリケーション(ボイスメール システム、自動転送、会議システムなど)が含まれます。
発信元デバイスとダイヤルされた宛先に応じて、ダイヤルされた宛先へのパスが選択されます。セカンダリ パスを使用できる場合、このパスもプライマリ パスに障害が発生したときに検討対象になります。
特定の宛先へのアクセスを許可または拒否することによって、複数のデバイス グループにそれぞれ別のサービス クラスを割り当てることができます。たとえば、ロビーにある電話からはシステム内部および市内の PSTN 宛先にしか到達できないようにし、その一方で、幹部社員の電話からは無制限に PSTN アクセスできるようにします。
ダイヤルしているデバイスからダイヤルされた宛先へのパスで、ダイヤル プランはダイヤルされた宛先に操作を適用できます。たとえば、ドイツの PSTN の宛先に到達するために、米国のユーザは 9011496901234 をダイヤルしますが、一方でフランスのユーザは 000496901234 をダイヤルすることで同じ宛先に到達することができる場合があります。このダイヤルされる宛先は、米国のゲートウェイの PSTN トランクには 011496901234 として示され、フランスにあるゲートウェイの PSTN トランクには 00496901234 として示される必要があります。
セッションの確立中とコール中に、発信側および着信側デバイスで、他のデバイスに関する情報が表示されます。コールの状態および方向に応じて、発信元、転送元、アラート側、接続先の情報が含まれます。ダイヤル プランで、表示される情報の形式と内容に影響するマッピングを定義できます。
この章では、システム設計者が、連絡先からのダイヤル、コンピュータやスマート フォンからのクリックツーコール アクション、モビリティ関連機能の採用などの、コンピューティング テクノロジーとテレフォニーがより緊密に統合された新機能を利用しつつ、テレフォニーおよびビデオ ユーザの従来のダイヤリング手順に対応するダイヤル プランを設計するために役立つ情報を示します。この章では、次の主要な領域に関する情報を示します。
ここでは、企業向け音声およびビデオ ダイヤル プランでよく使用される一般的な概念について説明します。
ここでは、Cisco Unified Communications Manager(Cisco Unified CM)と Cisco TelePresence Video Communication Server(VCS)を含む企業向けコラボレーション ソリューションのアーキテクチャ要素で使用できる各ダイヤル プラン要素を説明します。
ここでは、マルチ サイト コラボレーション ネットワーク、エンドポイントのアドレッシング、サービス クラスの構築に関連する設計ガイドラインを説明します。また、Unified CM と VCS のダイヤル プランの統合についても説明します。
詳細については、『 System Configuration Guide for Cisco Unified Communications Manager 』、『 Feature Configuration Guide for Cisco Unified Communications Manager 』、『Cisco IOS Voice and Video Configuration ガイド』、次の URL から利用できるその他の製品マニュアルを参照してください。
表 14-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
エンドツーエンドの企業のダイヤル プランの開発には、特定の製品に依存しないいくつかの概念の確実な知識が必要です。ここでは、次のような、これらの概念の概要を提供します。
呼処理エージェントに登録されているエンドポイント、ユーザ、およびアプリケーションの到達可能性は、アドレス指定可能なエンティティに割り当てられたアドレスによって提供されます。エンタープライズ コラボレーション ネットワークで、数値アドレスと英数字の Uniform Resource Identifier(URI)は区別されます。
数値アドレスは一連の数字で表されます。呼制御エージェントでは、数値アドレスに対して、特殊な構造を前提としたり、排除したりせず、必須のものでもありません。ダイヤル プランで使用される数値アドレス構造の決定は、ダイヤル プランの設計プロセスの一部です。
ITU 勧告 E.164 は、図 14-1 に示すように、PSTN で使用される数値の地理的アドレス(電話番号)の基本構造を定義します。
|
|
|
---|---|---|
|
|
|
図 14-1 には、次の定義が適用されます。
ITU 勧告 E.164 に従って、電話番号の最大長は 15 桁です。地理的な E.164 番号の最初の部分は、国番号です。国番号の長さは、1 ~ 3 桁です(1 桁の国番号は、国番号 1 および 7 だけです)。地理的な E.164 番号の残りの部分は、国内の最上位番号(NSN)です。NSN の一般的な構造は、最初の数桁が国内の宛先コード(NDC)またはエリア コードを表し、最後の数桁が加入者番号を表します。ITU 勧告 E.164 は国内番号計画を定義しないため、特定の国で NSN に使用するスキーマを規定していません。これは、国内番号計画の機関に任されます。次の URL で、さまざまな国別番号計画のドキュメントを入手できます。
https://www.itu.int/oth/T0202.aspx?parent=T0202
国内番号計画の構造は大きく異なる場合があります。例として、 表 14-2 で、米国とドイツで使用される番号計画を比較します。
|
|
|
|
---|---|---|---|
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 で、2 つの E.164 番号が、それぞれのサイトの DID 範囲に基づいて、同じサイト固有の 4 桁のディレクトリ番号になります。これは、4 桁の DN を数値エンドポイント アドレスとして直接使用できないことを意味します。
企業の番号計画に従うアドレスは、Enterprise Significant Number(ESN)とも呼ばれ、PSTN 番号(E.164 番号)が存在しない宛先にアドレスを指定するために使用できます。これらの宛先には、次のものが含まれます。
SIP URI に基づく英数字のアドレスも、エンドポイント、ユーザ、アプリケーションのアドレス指定に使用できます。英数字のアドレスに広く使用されている方式は、 ユーザ @ ホスト という簡略化された SIP URI で、左側(LHS、ユーザ部分)は英数字、右側(RHS、ホスト部分)はドメイン名です。次の例で、SIP URI に基づく有効な英数字のアドレスを示します。
これらの 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 を常に使用することを推奨します。
Unified CM の URI ルックアップ ポリシーは、必要に応じてエンタープライズ パラメータ [URI ルックアップ ポリシー(URI Lookup Policy)] を設定することで、大文字と小文字を区別するか(デフォルト)、区別しないかを設定することができます。
ユーザ、エンドポイント、アプリケーションなどの宛先へのダイヤリングは、さまざまな形式を使用して行うことができます。数値の +E.164 アドレス +496907739001 は、たとえば、次のいずれかとしてダイヤルできます。
これらの例は、ダイヤル文字列は通常、コンテキストで解釈されることを示しています。+E.164 アドレスを直接ダイヤルする場合を除き、ダイヤルされた文字列とコンテキストの組み合わせだけが適切な ID を目的の宛先アドレスに提供します。
「ダイヤリング手順」は、通常、特定の宛先のセットに到達するために使用される特定のダイヤリング動作を示します。いくつかの「ダイヤリング手順」の例を示します。
ダイヤリング手順は、ダイヤルされる文字列の形式(ダイヤリング構造)と、到達する宛先アドレス クラスの両方を指定することで説明されます。通常、企業のダイヤル プランで使用される宛先アドレス クラスの例は次のとおりです。
ダイヤル プランでサポートする必要があるダイヤリング手順を特定することは、企業ダイヤル プランの設計を開始する際の最初の手順の 1 つです。特定の発信者にサポートされる 2 つのダイヤリング手順間で重複が生じないようにダイヤリング手順を定義する必要があるため、サポートするすべてのダイヤリング手順の全体を把握してダイヤル プラン設計を開始することが不可欠です。これを守らない場合、呼制御において、番号が 1 つずつダイヤルされたときにその番号を分析することにより重複するダイヤリング手順を確定的に区別することができないため、ユーザ エクスペリエンスが損なわれます。これは最終的に、桁間タイムアウトにつながります。
英数字のダイヤリングでは、通常、完全修飾アドレスと非完全修飾アドレスだけを区別します。完全修飾アドレスには 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 のエンドポイントは異なるダイヤル ドメインに属します。
企業内のすべてのユーザ、アプリケーション、エンドポイントが同じ宛先のセットに到達できるわけではありません。到達可能な宛先のセットを制限する理由には、コストの回避、セキュリティ上の考慮事項、プライバシーなどがあります。たとえば、一部のユーザが国際通話を発信できない場合があります。ボイス メール システムは、電話料金の詐欺行為を防止するために、PSTN 宛先にコールできない場合があります。非常に限られたユーザだけが、会社の CEO に直接コールすることが許可される場合があります。許可される宛先の制限またはクラスのセットを示すためによく使用される用語が、 サービス クラス 、または CoS です。
コスト重視のサービス クラスの要件は、関連付けられた電話料金とコスト構造に大きく依存します。音声サービスが安価になる(または無料で使用できるようになる)に従い、より多くのサービス クラスの管理に関連する複雑さの増大と、削減可能なコールのコストの間のトレード オフは変化しています。たとえば、市内通話と国内通話の両方のコール タイプの料金が完全に同じになり、区別する意味がなくなる場合があります。
サービス クラスの定義は、時間のスケジュールに基づく場合もあります。特定の宛先へのアクセスが、特定の時間にのみ許可される場合があります。
企業ダイヤル プランの複雑さを軽減するために、区別されるサービス クラスの数を最小限にすることを推奨します。これは、有用性が低い、または有用性がないサービス クラスを削除するか(国内通話が原則無料にもかかわらず「国内」と「市内」のサービス クラスが区別されているなど)、(ほとんど)同等のサービス クラスを単一のサービス クラスに結合させることで実現できます。
通常、コストが発生する特定のユーザ、デバイス、アプリケーションによる特定のコール タイプへのアクセスとは別に、緊急サービス(911、112 など)へのアクセスは常にすべてのユーザに提供されなければなりません。したがって、すべてのサービス クラスで緊急サービスへのアクセスを常に可能にしなければなりません。
エンドツーエンドの企業ダイヤル プランでは、これらの側面をすべて考慮する必要があり、発信側と着信側のエンティティ間でルートを確立することだけに限定されません。
発信エンティティからの入力を受信した後、コール ルーティング プロセスの最初の手順は、使用されるダイヤリング手順を一義的に特定することです。英数字のダイヤリングの場合、完全修飾 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(欧州諸国のほとんどで一般的に使用)です。
前述のように、オーバーラップしないダイヤリング手順を選択することは桁間タイムアウトによるユーザ エクスペリエンスの低下を回避する鍵です。企業のダイヤル プランでよく見られるオーバーラップには、次のものがあります。
米国の NPA コードは 0 または 1 以外のあらゆる数字で始まる可能性があります。これは、10 桁のダイヤリングの最初の数桁が、ほとんどすべての短縮サイト内ダイヤリングとオーバーラップすることを意味します。
PSTN アクセス コード 9 は、9 で始まる内線へのすべての短縮サイト内ダイヤリングとオーバーラップします。
企業の短縮オンネット番号計画用に選択されたアクセス コードが、同じ数字で始まるサイト間ダイヤリングの範囲とオーバーラップする可能性があります。たとえば、短縮オンネット サイト内ダイヤリングにアクセス コード 8 を使用した場合、8 で始まる短縮サイト内ダイヤリングを使用できなくなります。
コール パーク番号やボイス メールなどの機能へのアクセスも、定義されたダイヤリング手順のセットにマッピングする必要があります。これらの機能へのダイヤリングは、通常、短縮ダイヤル手順だけを必要とします。これを実現するには、機能アクセス コードを短縮サイト内ダイヤリングにマップするか、専用の機能アクセス コードを定義する必要があります。
オンネット/サイト間の宛先とオフネットの宛先へのダイヤリング手順で、同じダイヤリング構造を使用することは珍しくありません。この場合、呼制御が、アドレス指定されたエンドポイント、ユーザ、アプリケーションがオンネットかオフネットかをダイヤルされたアドレスに基づいて決定し、コールをそれぞれオンネットまたはオフネットとして扱います。
図 14-4 に、強制されたオンネット ルーティングの例を示します。この例の 4 つのコールは、91 プラス 10 桁としてダイヤルされます。ただし、+ 1 408 555 2345 と + 1 212 555 7000 へのコールは、実際にはオフネット コールとして PSTN ゲートウェイを介してルーティングされますが、他の 2 つのコールは呼制御がオンネット宛先として最終的な宛先を識別するため、オンネット コールとしてルーティングされます。強制オンネット ルーティングは、特定の宛先のダイヤルに使用されるダイヤリング手順が必ずしもコールのルーティング方法を決定するわけではないことも明確に示します。この例で、使用された PSTN ダイヤリング手順でオフネットの宛先が呼び出されることが示されている場合でも、一部のコールはオンネット コールとしてルーティングされます。
強制オンネット ルーティングは、ディレクトリからの +E.164 宛先のダイヤリングが実装されている場合に、特に重要です。正規化されたディレクトリでは、番号に関連付けられているユーザが内部か外部かに関係なく、すべての宛先が +E.164 番号として定義されます。この場合、強制オンネット ルーティングは、PSTN を通じて内部コールをルーティングすることで発生する料金を回避するために必須です。
すべてのエンドポイントが単一の呼制御に登録された場合、この呼制御がすべての既知のオンネット宛先を完全に認識できます。定義されたダイヤリング手順のいずれかを使用してユーザ、エンドポイント、またはアプリケーションが宛先をダイヤルしたときに、呼制御はダイヤルされた宛先がオンネットかオフネットかを容易に判断できます。これは、使用されたダイヤリング手順またはダイヤルされた正規化アドレスに基づきます(強制オンネット ルーティングを参照してください)。
ダイヤルされた宛先が外部だと判断されると、呼制御は、コールをセット アップするために正しい外部ルートを選択する必要があります。1 台の外部(PSTN)接続だけがある場合、これは簡単に決定できます。複数の外部接続がある場合は、次の要因を任意に組み合わせて出力ルートを選択できます。
ダイヤルされた宛先に基づいて外部接続を選べるように、ダイヤルされる宛先を分類する必要があります。前述したとおり、E.164 番号は番号が地理的な関係を意味する階層構造になっていて、出力接続の選択が宛先に(E.164 番号の地理的な意味で)「最も近い」出力ポイントを選択するプレフィックス ベースの階層型ルーティング スキームに基づきます。この動作はテールエンド ホップオフ(TEHO)と呼ばれます。テールエンド ホップオフを実装するときは、地域の規制を考慮しなければなりません。
市内電話(州内)より国内通話(州間など)のほうが低価格になる変わった通話料金では、TEHO の特別なケースが発生します。この場合は、ダイヤルされた宛先に「近すぎる」出力接続を実際には選択しないように、出力ポイント選択ポリシーを実装する必要が生じる場合があります。電話料金が下がれば、このようなルーティング スキームの有効性は低下します。
左側の英数字に最も重要な情報がある、明確に階層化された地理的な構造を持つ E.164 番号とは対照的に、SIP URI では、URI のホスト部分(RHS)でアドレスを階層化できます。RHS として使用されるドメイン名によっては、URI のアドレス階層は、特に user@example.org などのフラットな URI スキームが使用されている場合、必ずしもルーティング トポロジのロケーションに対して URI の地理的なマッピングが許可されるわけではありません。より興味深い点として、SIP URI の最も重要な要素は、ホスト部分の右端のデータです(トップ レベル ドメイン)。
大規模な企業ネットワークでは、多数の呼制御が導入されている場合があります。これらの独立した呼制御は、トランクを使用して相互に接続されます。可能なトポロジには、ハブ アンド スポーク、フル メッシュ、およびこれらの組み合わせがあります。これらの呼制御のいずれかが個別に、エンドポイント、ローカルに登録されたアプリケーション、または内部および外部トランクによって提供されたコールをルーティングします。
このような環境では、前の項で説明したオンネット/オフネットの決定が少し複雑になります。コールを外部接続にルーティングする前に、各呼制御が、ダイヤルされた宛先がほんとうにオフネットであることを確認する必要があります。しかし、ローカルに登録されたアドレスだけを確認しても、呼制御は、実際には信頼性の高いローカル/リモートの決定ができるだけで、リモート(ローカルに登録されていない)として分類された宛先がオンネットであり、導入されている他のエンタープライズ呼制御のいずれかでホストされている可能性があります。
個々の呼制御に数値アドレスを設定し、エンドポイントを厳密に地理的に割り当てて、特定の呼制御で正しい内部または外部接続を選択するには、E.164 プレフィックスに基づくルーティング方式を実装する必要があります。これは基本的に、プレフィックス ベースのルーティングに使用する接続の一部が外部接続(たとえば、PSTN への接続)ではなく、企業の他の呼制御エンティティへの内部接続であるという点を除いて、単一の呼制御の例で説明したコール ルーティング プロセスと同じです。リモート オンネットの宛先へのコールだけがリモート呼制御にルーティングされるようにするために、リモート呼制御に対してローカルな特定のアドレス範囲に基づき、コール ルーティングを決定する必要があります。
図 14-5 に、独立した呼制御間のプレフィックス ベースのルーティングをごく限定的にする必要がある理由を示します。この例では、左側の呼制御が 912125556001 をオンネット コールとして処理する必要があるかどうかを判断できるようにするために、左側の呼制御が、右側の呼制御エンティティによって提供されたすべての数値アドレスに対して特別な数字プレフィックス ルートを持っていなければなりません。
各呼制御でプロビジョニングされたオンネット プレフィックス ルートのメンテナンスは、関係する呼制御数や、考慮すべきサイト数と DID 範囲の増加により、より複雑になりました。リモート宛先のダイナミック学習は、この複雑さを解消するのに役立ちます。グローバル ダイヤル プラン レプリケーション(GDPR)は、呼制御がリモート呼制御に存在する宛先を自動的に学習できるようにするアーキテクチャの 1 例です。
図 14-5 呼制御間のプレフィックス ベースのルーティング
英数字 URI の数値アドレス プレフィックス ベース ルーティングは、ドメインの階層を使用して、URI のホストまたはドメイン部分に基づいてルーティングを実行することと同じです。図 14-6 に、アルファベット URI を使用する階層型ルーティングの例を示します。この例では、階層的なドメイン構造に基づいてオンネット ルーティングを容易に実装できるように、3 個の独立した呼制御がすべて専用(サブ)ドメインを使用します。
URI のアドレッシング方式が非階層の場合、各呼制御はリモート呼制御でホストされているすべての URI を認識する必要があります。グローバル ダイヤル プラン レプリケーション(GDPR)は、フラットな URI の命名方式でも確定的なルーティングを可能にするために、各呼制御でホストされている URI に関する情報を交換するために呼制御のためのメカニズムを提供します。
ここでは、次のソリューション コンポーネントで使用可能なダイヤル プラン要素について説明します。
Cisco Unified Communications Manager(Unified CM)に含まれている次のダイヤル プラン要素について、設計と設定のガイドラインを示します。
(注) さまざまな種類の IP 電話で、キーパッド入力が使用でき、視覚的な情報をさまざまな方法で提供します。この章では説明のため、次のタイプの電話機を定義します。
発信側トランスフォーメーション パターンによって、システムは発信者番号をさまざまな形式に適応させることができます。最も一般的な用途は、グローバル化された発信者番号からローカル化された番号に適応させること、およびその逆です。
トランスフォーメーション パターンは、照合される発番号の数値表現で構成されます。使用される構文は、ルート パターン、着信側トランスフォーメーション パターン、ディレクトリ番号などのその他パターンの構文と同じです
トランスフォーメーション パターンの変換演算子には、数字破棄命令(ドット前の番号など)、発信側トランスフォーメーション マスク、プレフィックス番号、発信側の外線電話番号マスクを適用するオプションが含まれます。また、発信側のプレゼンテーション インジケータ([デフォルト(Default)]、[許可(Allowed)]、または [制限(Restricted)])を設定できます。
パーティションおよびコーリング サーチ スペースによって、どの発信側トランスフォーメーション パターンをどの電話機に適用するかどうかが制御されます。電話機では、デバイス プールの発信側トランスフォーメーション コーリング サーチ スペース(CSS)またはデバイス固有の発信側トランスフォーメーション CSS を優先順位の低い順に使用できます。
IP Phone では、発信側トランスフォーメーションを電話機から発信されたコールと電話機で終了したコール用に設定できます。
電話機の場合、電話が鳴っている間に表示される番号が、発信またはリモート番号の発信側トランスフォーメーションの影響を受けます。
発信コールの発信側トランスフォーメーション CSS(ローカリゼーションやリモート番号の発信側トランスフォーメーション CSS とも呼ばれる)を使用して、リモート接続されている通話者情報をローカライズすることもできます。この機能を有効にするには、拡張サービス パラメータ [リモート番号にトランスフォーメーションを適用(Apply Transformations On Remote Number)] を有効にする必要があります。
ローカライズされた通話者情報を電話機に提供できることで、通話切換機能が呼び出された場合でも一貫したリモートの通話者情報を IP Phone に表示できます。
タイプ A 電話機では、キーパッドを使用して + 記号をダイヤルすることはできません。タイプ B 電話機では、0 キー(Cisco Unified IP Phones 7921 および 7925)または * キー(他のすべての電話機モデル)のいずれかを押したままにして + 記号をダイヤルできます。Cisco Unified Personal Communicator エンドポイントでは、+ 記号はコンピュータのキーボードを使用して入力するか、エンドポイントのクリックツーダイヤル機能の使用時に入力文字列の一部として入力します。
タイプ A の電話機では、+ 記号のダイヤルはサポートされていません。+ 記号は、着信コールの発呼側情報としてディレクトリ内に表示できますが、エントリが不在着信のディレクトリからダイヤルされる場合、電話は + 記号を除去します。かけ間違いを回避するために、タイプ A の電話機は、不在着信ディレクトリに変換された番号を置き、コールバックも変換された番号を使用します。変換された番号は、ディレクトリからのかけ間違いを回避するため、ダイヤル プランによってサポートされるダイヤリング手順の形式にする必要があります。
一部のエンドポイントでは、着信コールで発信者番号を + を番号の一部に含めて表示することができます。コールが電話機に提供されたとき、呼び出し中の電話機に表示される番号は、設定された発信者番号トランスフォーメーション パターンによって処理されます。不在コールと受信コールのディレクトリは、元の変換前の番号と変換された番号の両方を保持できます。一部のエンドポイントでは、リストに表示される番号は変換された番号になり、変換前の番号はエントリの詳細を確認したときにだけ表示されます。ダイヤル プランが + ダイヤリングをサポートする限り、一部のエンドポイントのディレクトリからダイヤルされた番号は元の変換前の番号であり、発信者番号の一部として + 記号が使用された以前の受信コールをワンタッチでダイヤルできるようになります。他のエンドポイントでは、ディレクトリからダイヤルされる番号は変換された番号です。ワンタッチでのダイヤリングを許可するには、この番号をダイヤル プランでサポートされているダイヤリング手順の形式にする必要があります。
New York にあるタイプ B 電話機が +1 408 526 4000 からのコールを受信します。発信側トランスフォーメーション パターンは、電話機のデバイス プールの発信側変換 CSS に配置されています。パターンの 1 つは \+1.!(ドットの前の番号を削除)と設定されています。
コールが鳴ると、着信側電話機に着番号 4085264000 が表示されます。コールに応答し、コールを解放した後、受信コール ディレクトリには最後のコールが 408 526 4000 として表示されますが、ユーザがディレクトリ エントリからコールバックを開始したときの着信番号は +1 408 526 4000 です。
SCCP を使用する IP Phone は、すべてのユーザ入力イベントをただちに Unified CM に報告します。たとえば、ユーザがオフフックにするとすぐに、その電話機が登録されている Unified CM サーバに電話機からシグナリング メッセージが送信されます。電話機は 1 つの端末と考えることができ、設定されたダイヤル プランに従い、ユーザ入力に起因するすべての決定がその端末で Unified CM によって下されます。
その他のユーザ イベントが電話機で検出されると、そのイベントは個別に Unified CM にリレーされます。オフフックして 1000 をダイヤルしたユーザは、電話機から Unified CM に 5 つの独立したシグナリング イベントをトリガーすることになります。その結果としてユーザに提供されるフィードバック、たとえば画面メッセージ、ダイヤル トーンの再生、2 次ダイヤル トーン、リングバック、リオーダーなどは、Unified CM がダイヤル プラン設定に基づいて電話機へ発行するコマンドです(図 14-7 を参照)。
図 14-7 SCCP 電話機でのユーザ入力とフィードバック
SCCP を実行する IP Phone 上にダイヤル プラン情報を設定する必要はなく、また設定できません。ダイヤル プラン機能は、ユーザ入力が収集されたときのダイヤリング パターンの認識も含めて、すべて Unified CM クラスタに含まれています。
ユーザのダイヤルしたパターンが Unified CM に拒否された場合は、そのパターンが Unified CM の番号分析でベストマッチになるとすぐに、そのユーザに対してリオーダー トーンが再生されます。たとえば、1 分刻みで課金される番号計画エリア(または市外局番)976 へのコールがすべて拒否される場合は、ユーザが 91976 をダイヤルするとすぐに、そのユーザの電話機にリオーダー音が送信されます。
タイプ A 電話機はタイプ B 電話機と動作が少し異なり、タイプ B 電話機では Key Press Markup Language(KPML)がサポートされていますが、タイプ A 電話機ではサポートされません(タイプ B の 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 をダイヤルして桁間タイムアウトの時間だけ待つと、電話機は 15 秒後に内線 1000 にコールをつなぎます。
(注) ユーザが [Redial] ソフトキーを押した場合は、ただちに処理が行われるため、ユーザは Dial キーを押したり、桁間タイムアウトを待ったりする必要がありません。
ユーザが Unified CM に拒否されるパターンをダイヤルした場合、そのユーザはパターン全体を入力して Dial キーを押し、INVITE メッセージを Unified CM に送信した後でなければ、コールが拒否されたという通知(リオーダー トーン)は発信元に送信されません。たとえば、NPA 976 へのコールがすべて拒否される場合は、リオーダー音が再生される前に 919765551234 をダイヤルして [ダイヤル(Dial)] を押す必要があります。
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 電話機はタイプ A 電話機と動作が少し異なり、タイプ B 電話機では Key Press Markup Language(KPML)がサポートされていますが、タイプ A 電話機ではサポートされません(タイプ A の 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 プロトコルを実行する電話機のユーザ インターフェイスとの整合性が取れています。
タイプ 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 のキーを押した後)にリオーダー トーンを受信します。
Cisco Unified CM には、ユーザ入力が収集されたときに電話機でパターン認識を実行できるように、SIP ダイヤル規則機能が備わっています。たとえば、誰もが知る 911 というパターンを認識したら Unified CM にメッセージを送信し、すぐに緊急コールが開始されるように電話機を設定できます。それと同時に、ユーザが国際電話番号の可変長のパターンを入力できるようにも設定できます。
注意すべき重要な点は、SIP ダイヤル規則を使用して電話機にパターン認識を設定しても、Unified CM のサービス クラスとルート プランの設定の方が優先されることです。ある電話機が長距離通話のパターンを認識するように設定されていても、その電話機がローカル コールのみを許可するサービス クラスに割り当てられていると、Unified CM がそのコールをブロックします。
SIP ダイヤル規則には、それらの規則を設定する電話機のモデルに基づいて、次の 2 つのタイプがあります。
ダイヤル規則の一部として使用できる基本的なダイヤル パラメータは、次の 4 つです。
このパラメータは、パターンの実際の数値表現です。数字、ワイルドカード、2 次ダイヤル トーンを再生する命令を含めることができます。次の表は、2 つのタイプのダイヤル規則について、値とその効果を示しています。
このパラメータは、ダイヤル パターンの適用対象となるボタンを指定します。ユーザが回線ボタン 1 でコールを開始しようとしている場合は、ボタン 1 用に指定されたダイヤル パターンのみが適用されます。このオプション パラメータを設定しなかった場合、ダイヤル パターンは電話機のすべての回線に適用されます。このパラメータは、Cisco SIP IP Phone 7940、7941、7942、7945、7960、7961、7962、7965、7970、7971、および 7975 のみに適用されます。ボタン番号は、画面横にあるボタンの上から下の順に対応し、一番上のボタンが 1 になります。
このパラメータは、システムがタイムアウトになり、ユーザが入力した番号にダイヤルするまでの時間を秒単位で指定します。ダイヤルされた番号がすぐにダイヤルされるようにするには、0 を指定します。このパラメータは、7940_7960_OTHER ダイヤル規則にのみ適用されます。このパラメータを省略した場合は、電話機のデフォルトの桁間タイムアウト値(デフォルトは 10 秒)が使用されます。
このパラメータは、ダイヤルされた番号に自動的に追加されるタグを表します。有効な値は、 IP (Unified CM 以外の SIP コール エージェントが配置される場合)と Phone です。このパラメータは、7940_7960_OTHER ダイヤル規則にのみ適用されます。このパラメータはオプションであり、Unified CM が唯一のコール エージェントとなる配置では省略してください。Unified CM に送信される 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 をダイヤルした場合に選択されるパターンを示しています。
|
|
|
---|---|---|
Unified CM 内に設定される数字のダイヤリング宛先およびディレクトリ URI は、すべて内部のコール ルーティング テーブルにパターンとして追加されます。このような宛先としては、IP Phone 回線、ボイスメール ポート、ルート パターン、トランスレーション パターン、および CTI ルート ポイントがあります。Unified CM は、数字ダイヤル先とディレクトリ URI に 2 つの異なるルーティング テーブルを使用します。
ディレクトリ URI がダイヤルされたとき、Unified CM は完全一致ロジックを使用して、ディレクトリ URI ルーティング テーブル内の設定済みディレクトリ URI から一致を検索します。[URI ルックアップ ポリシー(URI Lookup Policy)] エンタープライズ サービス パラメータ設定は URI のユーザ部分(左側)の完全一致ロジックが大文字と小文字を区別するかしないかを決定します。大文字と小文字を区別するマッチングがデフォルトです。番号がダイヤルされると、Unified CM は best-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! がある場合に、これらの一致する可能性があるパターンの一致する文字列の数を示します。
|
|
|
---|---|---|
この例では、変数長パターン 13! がベストマッチとして選択されています。
(注) Cisco Unified CM でディレクトリ番号(DN)を設定すると、それぞれのデバイス(IP Phone など)が登録済みかどうかにかかわらず、その番号はコール ルーティング テーブルに配置されます。この仕様によって、デバイス(およびそのプライマリ パターン)が未登録である場合は、セカンダリの一致パターンを利用してフェールオーバー機能をアプリケーションに提供することができなくなりました。プライマリ パターンがコール ルーティング テーブルに必ず存在するため、セカンダリ パターンに一致するかどうかは検索されません。
Unified CM 内のすべてのパターン(ルート パターン、トランスレーション パターン、ディレクトリ番号など)では、+ 記号を使用できます。+ を文字どおりの意味で使用するには、+ の前にエスケープ文字 \ を入力することで、先行文字の 1 つ以上のインスタンスを意味する正規表現演算子の + と区別します。次に例を示します。
Unified CM に登録されているすべてのエンドポイントは、1 つ以上の数字(先頭に + が付く場合もある)を含むディレクトリ番号でプロビジョニングされます。最大 5 つのディレクトリ URI を各ディレクトリ番号に関連付けることができます。この関連付けは、ディレクトリ URI をディレクトリ番号に明示的に関連付けることで作成できます。ディレクトリ URI がエンド ユーザに設定されている場合、そのエンドユーザにプライマリ内線番号が定義されるとすぐに、このディレクトリ URI が自動的にそのエンドユーザのプライマリ内線番号と関連付けられます。すべての自動的に関連付けられたディレクトリ URI はパーティション ディレクトリ URI に作成されますが、手動設定されたディレクトリ URI はどのパーティションにも置くことができます。手動で設定されたディレクトリ URI は、関連付けられているディレクトリ番号と同じパーティションに配置できますが、そうしなくてもかまいません。ディレクトリ URI はパーティションごとに一義的でなければなりません。
正確には、ディレクトリ番号に関連付けられたディレクトリ URI の 1 つが、そのディレクトリ番号のプライマリ ディレクトリ URI としてマークされる必要があります。ユーザ ディレクトリ URI がそのユーザのプライマリ内線番号に自動的に関連付けられる場合、そのディレクトリ URI は自動的にそのディレクトリ番号のプライマリ ディレクトリ URI にもなります。自動的に関連付けられたディレクトリ URI がない場合、設定されたディレクトリ URI の 1 つがプライマリ ディレクトリ URI として選択される必要があります。プライマリ ディレクトリ URI の目的は、このディレクトリ URI がそれぞれのディレクトリ番号から発信されたコールについて、発信 ID ディレクトリ URI として使用されることです。
ディレクトリ URI をどのディレクトリ番号とも関連付けすることが可能なため、関連付けられたディレクトリ URI をダイヤルすることで、発信者はどのディレクトリ番号にも到達できます。着信側ディレクトリ番号は、任意のプロトコルを使用して Unified CM に登録された任意のデバイスになります。同様に、Unified CM は、ディレクトリ URI が発信側ディレクトリ番号に関連付けられている限り、どのディレクトリ番号からのコールにもディレクトリ URI 発信者 ID を提供できます。
ディレクトリ URI のクラスタ間ルーティングを有効にするために、クラスタ間検索サービス(ILS)で他のクラスタとディレクトリ URI カタログを交換するように Unified CM をプロビジョニングできます。他のクラスタとディレクトリ URI カタログを交換するように設定された各クラスタは、ロケーション属性、SIP ルート文字列とともに、すべてのローカルに設定されたディレクトリ URI を 1 つのディレクトリ URI カタログでアドバタイズします。マルチ クラスタ環境では、ディレクトリ URI のホスト部分を使用して SIP 要求を確実にルーティングすることができない場合に、ディレクトリ URI へのコールを正しいクラスタに転送するために、このロケーション属性が使用されます。これは、たとえば、 <user>@example.com などのフラットな URI スキームを使用する場合です。ホスト部分の「example.com」は、この URI をホストするリモートの Unified CM クラスタを一義的に識別しません。
リモート クラスタから学習したディレクトリ URI へのコールをルーティングする方法の詳細については、Unified CM での SIP 要求のルーティングの項を参照してください。
トランスレーション パターンは、Unified CM で最も強力な番号操作ツールであり、あらゆるタイプのコールに対して使用できます。トランスレーション パターンは、ルート パターンと同じ一般規則に従い、同じワイルドカードを使用します。ルート パターンと同じように、トランスレーション パターンをパーティションに割り当てます。しかし、ダイヤルされた数字がトランスレーション パターンと一致する場合、Unified CM は、ゲートウェイなどの外部エンティティにコールをルーティングしません。代わりに、まず変換を実行した後、トランスレーション パターン内で設定されたコーリング サーチ スペースを使用して、コールを再度ルーティングします。
トランスレーション パターンは、図 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 ディレクトリには、常にユーザがダイヤルしたストリングがそのまま表示されます。
トランスレーション パターンの一般的な使用例は、特定のダイヤル文字列の形式から他のダイヤル プラン要素がマッチする文字列でマッピングを作成することです。このマッピングは、ルート パターン、ディレクトリ番号などのその他パターンによって作成された「ネイティブ」ダイヤリング手順にオーバーレイのダイヤリング手順を実装します。セカンダリ ルックアップでは通常、ダイヤリングの正規化を実行するトランスレーション パターンはトランスレーション パターンをアクティブにするコーリング サーチ スペースを単純に使用する必要があります。CSS 継承と呼ばれるこの動作は、トランスレーション パターンのオプション [発信側コーリング サーチ スペースを使用(Use Originator's Calling Search Space)] で選択します。このオプションを有効にすると、別のコーリング サーチ スペースによってそれぞれ定義された異なるサービス クラスのダイヤリングの正規化トランスレーション パターンを再利用できるようになります。
Unified CM は、同じクラスタ内の内部宛先にコールをルーティングする方法を自動的に「認識」します。PSTN ゲートウェイ、SIP トランク、またはその他の Unified CM クラスタなどの外部宛先の場合、外部ルート コンストラクト(次の項で説明)を使用して、明示的にルーティングを設定する必要があります。このコンストラクトは、3 層式のアーキテクチャに基づいています。このアーキテクチャでは、複数層のコール ルーティングと共に、番号操作も可能です。Unified CM は、外部ダイヤル ストリングと一致する設定済みルート パターンを検索し、それを使用して、対応するルート リストを選択します。ルート リストには、コールに使用可能なパスが優先順位順に並べられています。これらのパスは、ルート グループと呼ばれ、従来の PBX でトランク グループと呼ばれていたものに非常によく似ています。図 14-14 では、Unified CM 外部ルート コンストラクトの 3 層式アーキテクチャを示しています。
ルート パターンは、コールを外部エンティティにルーティングするために Unified CM で設定された、数字とワイルドカードを組み合わせたストリング(たとえば、9.[2-9]XXXXXX)です。ルート パターンでは、コールをルーティングするゲートウェイを直接指すことも、ルート リストを指すこともできます。ルート リストはルート グループを指しており、最終的にゲートウェイを指します。
ルート パターン、ルート リスト、およびルート グループ コンストラクトを完全パスで指定することを強く推奨します。その理由は、この構造を使用するとコール ルーティング、番号操作、および将来のダイヤル プランの拡張を最も柔軟に行うことができるからです。
https://www.cisco.com/en/US/products/sw/voicesw/ps5629/prod_maintenance_guides_list.html
– ダイヤルの終わりを指定する 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 に設定します。
SIP ルート パターンは、Unified CM で設定され、SIP URI のホスト部分(右側)に基づいて外部エンティティへのコールをルーティングまたはブロックします。SIP ルート パターンは、SIP トランクまたは 1 つ以上のルート グループに続いて最後に SIP トランクを参照するルート リストを直接ポイントすることができます。いっそうの柔軟性のために、フル SIP ルート パターン、ルート リスト、ルート グループ コンストラクトの使用を推奨します。
SIP URI のホスト部分に一致する SIP ルート パターンは、ドメイン名または IP アドレス(両方とも SIP URI の右側にある可能性がある)と一致する場合があります。ドメイン名の SIP ルート パターンでワイルドカードを使用して、複数のドメインに一致させることができます(たとえば、*.cisco.com や ccm[1-4].uc.cisco.com)。IP アドレスの SIP ルート パターンでは、サブネット表記を使用できます(たとえば、192.168.10.0/24)。
ルート リストは、発信コールに使用できるパス(ルート グループ)が優先順位順に並べられたリストです。ルート リストの標準的な用途は、リモートの宛先に 2 つのパスを指定することです。この場合、第一選択のパスは、IP WAN を介したパスであり、第二選択のパスは、PSTN ゲートウェイを介したパスです。
2. ルート パターンまたはルート グループで定義されている発信側および着信側トランスフォーメーション
出力デバイス(ゲートウェイまたはトランク)に定義された発信側および着信側トランスフォーメーションは、ルート パターンとルート グループで定義された発信側および着信側トランスフォーメーションを上書きすることに注意してください。
ルート グループは、一般にゲートキーパーまたはリモート Unified CM クラスタとのゲートウェイ(MGCP、SIP、または H.323)、H.323 トランク、または Cisco Unified Border Element である特定のデバイスを制御し、それを指定します。Unified CM は、割り当てられている分配アルゴリズムに従ってコールをデバイスに送信します。Unified CM では、トップダウン アルゴリズムと循環アルゴリズムをサポートしています。
ルート グループ デバイスは、ルート グループによってアクセスされるエンドポイントであり、一般に、ゲートキーパーまたはリモート Unified CM とのゲートウェイまたはトランクで構成されます。次のタイプのデバイスは、Unified CM で設定できます。
(注) 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-16 に示すように、同じルート パターンを変更して、標準ローカル ルート グループを含むルート リストを指すようにした場合、Dallas サイトから発信されるコールの出口は Dallas ゲートウェイを経由した公衆網となり、New York サイトから発信されるコールの出口は New York ゲートウェイを経由した公衆網となり、San Francisco サイトから発信されるコールの出口は San Francisco ゲートウェイを経由した公衆網となります。
ローカル ルート グループを使用すると、発信元デバイスに基づいて出力ゲートウェイを選択できます。これにより、すべてのサイトの電話機のコーリング サーチ スペースによって再利用が可能な、サイトに依存しないルート パターンが使用できるようになります。
デバイス モビリティ機能を使用すると、ローミングしている現在のサブネットに基づいて、デバイス プールをエンドポイントに割り当てることができます。これにより、電話機の現在のサイトに基づいた、ローカル ルート グループの割り当てが可能になります。
電話機を 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 はプロバイダーによってスクリーニングされません。管理者による転送コールのローカル ルート グループの選択ポリシーの設定を許可するサービス パラメータがあります。サービス パラメータは次のように設定できます。
中央ゲートウェイが設定されているシステムの場合、ローカル ルート グループによって、PSTN へのローカル フェールオーバーが簡素化されます。発信側サイトでゲートウェイへのローカル フェールオーバーが許可されているときに、単一のルート リストを使用することで、複数サイトの PSTN コールをルーティングできます。
ある会社が、Chicago にあるトランクのグループに有利な PSTN 相互接続レートをネゴシエートするとします。ルート リストに、1 番めの項目として Chicago にあるゲートウェイを含むルート グループが含まれ、2 番めの項目として標準ローカル ルート グループが含まれている場合、処理されるコールは最初に Chicago にある低コストの推奨ゲートウェイに送信されます。Chicago ゲートウェイが使用可能でない、フリー ポートがない、あるいは発信側電話機と Chicago ゲートウェイ間で使用できる帯域幅が十分でない場合は、発信側電話機のデバイス プール設定でローカル ルート グループによって決定されている、2 番めの項目を使用して、発信側電話機と同じ場所にあるゲートウェイを経由したコールのルーティングが試行されます(図 14-17 を参照)。
図 14-17 PSTN へのローカル フェールオーバーを使用した中央ゲートウェイ
発信側デバイス固有の複数のルート グループ要素を持つルート リストをサポートするために、複数の名前付きローカル ルート グループを Unified CM で設定できます。すべてのローカル ルート グループの名前をシステム レベルで定義した後、名前付きローカル ルート グループあたりのルート グループをデバイス プール レベルで設定できます。これによって、たとえば、緊急通話、国内 PSTN 宛先およびその他の宛先に使用する異なるローカル ルート グループを定義できます。複数のローカル ルート グループを使用することによって、異なるゲートウェイをさまざまなコールのタイプに選択することができます。たとえば、緊急通話に対してのみ使用すべき小規模な PSTN ゲートウェイがある小規模サイトで、その小規模サイトの PSTN コールが主要なハブの PSTN リソースを使用する必要がある場合は、次のローカル ルート グループの設定を使用することもできます。
|
|
|
---|---|---|
|
|
|
この例では、主要なハブ(SFO または MCO)のゲートウェイは、ハブに関連付けられたハブ サイトとブランチ サイトのユーザによって PSTN コールに使用され(SJC および OAK は SFO、TPA および MIA は MCO を使用)、緊急通話は常にローカル PSTN リソースを使用します。
図 14-18 に緊急通報のコール ルーティングとローカル ルート グループの選択を示します。緊急ルート パターンによって使用されるルート リスト RL_911 には、最初のルート グループ エントリとして LRG_Emergency があります。ルート リストの 2 番目のエントリは標準ローカル ルート グループを参照し、デバイス プールで定義されたデフォルト PSTN リソースがフェールオーバーとして選択されていることを確認します。緊急通話が発信され、ルート リスト エントリ LRG_Emergency が選択されるたびに、Unified CM はプレースホルダ LRG_Emergency の参照を解除し、代わりに発信側デバイスのデバイス プールで LRG_Emergency に設定したルート グループを使用します。緊急通報用のサイト SFO および SJC の電話、ローカル PSTN ゲートウェイがどのように選択されるかを例に示します。
図 14-18 複数のローカル ルート グループによる緊急通報ルーティング
同様の概念を利用して、サイトに依存しない PSTN ルート パターンは LRG_PSTN を使用するルート リストを指すように定義できます。LRG_PSTN は、名前付きローカル ルート グループ LRG_PSTN のデバイス プール レベルで定義されたルート グループへの参照が解除されます。サイト SJC および SFO からの PSTN コールが、デバイス プール ローカル ルート グループ設定に基づいて、どのようにサイト SFO の中央 PSTN ゲートウェイにルーティングされるかを図 14-19 に示します。
図 14-19 複数のローカル ルート グループによる PSTN コール ルーティング
未定義のローカル ルート グループは、出力ルーティング デバイスの選択中にスキップされます。ルート リストに、発信側デバイスのデバイス プールにルート グループが割り当てられていないローカル ルート グループが含まれていると、ルート リストのこのエントリはスキップされ、ルート リストの次のルート グループのメンバーが考慮されます。ローカル ルート グループのみを含むルート リストを使用する場合、実ルート グループに一度も到達せずルート リストが枯渇することによって出力コールがドロップされないよう、すべての発信元デバイスのすべてのデバイス プールで一貫してルート グループを定義することが重要です。
すべてのルート リストの最後のエントリとして常に標準ローカル ルート グループを使用し、すべてのデバイス プールで標準ローカル ルート グループのルート グループが選択されるようにすることは、上記のルート リストの枯渇の問題を回避するための安全対策メカニズムとして使用できます。
トランスレーション パターン、ルート パターン、DN は緊急パターンとして設定できます。緊急パターンのデフォルト値は、トランスレーション パターンでは緊急、ルート パターンと DN では非緊急になりす。ルート パターン、トランスレーション パターン、DN の緊急パターンのみが設定できます。他のパターンは、すべて非緊急状態になります。
パターンを緊急としてマーキングすることは、一般に、パターンに一致したコールを 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] を使用してコールをルーティングします。
図 14-20 の 9011.! のような可変長緊急トランスレーション パターンは、桁間タイムアウトを強制しません。ダイヤルされた番号が受信され、数字ごとに分析されて、緊急トランスレーション パターンが唯一の一致(またはベストマッチ)になるとすぐに、トランスレーション パターンで定義された番号変換が実行され、トランスレーション パターンの CSS によって定義されるセカンダリ ルックアップがただちに実行されます。
図 14-20 で示す設定がある場合、ユーザが 901133158405858 とダイヤルすると、コールは最後の数字がダイヤルされた直後にルーティングされます。コールはトランスレーション パターン 9011.! と一致し、ダイヤルされた番号は +3333158405858 に変換され(9011 が廃棄され、+ が前に付きます)、固定長の PSTN ルート パターン \+33XXXXXXXXX(フランスで使用される 9 桁の NSN)に一致します。
一方、ユーザが 9011496907739001 とダイヤルすると、桁間タイムアウトが発生します。9011.! との一致後、結果の番号 +496907739001 はルート パターン \+! に一致し、Unified CM は、発信者が以降の番号をダイヤルするつもりがないことを確認するために、次の番号を待機する必要があります。以降にダイヤルされた番号も同じルート パターンに一致します。
図 14-20 では、緊急トランスレーション パターンを使用して短縮オフネット ダイヤリング手順を実装するいくつかの例も示します。8 で始まる両方のトランスレーション パターンが 8 桁をそのまま受け入れ、ダイヤルされた番号を +E.164 にトランスフォームし、セカンダリ ルックアップを実行します。
83315858 にダイヤリングすると、桁間タイムアウトなしで、すぐにルーティングされます。ダイヤルされた番号は固定長のトランスレーション パターン 8331.5XXX と一致し、変換された着信者番号 +33158405858 は固定長のルート パターン \+33XXXXXXXXX に一致します。
ただし、84969001 にダイヤリングしても、デフォルトではただちにルーティングされません。ダイヤルされた番号が固定長のトランスレーション パターン 8496.9XXX に一致し、変換された着信者番号 +496907739001 は可変長の PSTN ルート パターン \+! に一致します。この例は、中間トランスレーション パターン一致の緊急パターンでも固定長でもない特性が、中間トランスレーション パターンに設定されている CSS によって定義されたセカンダリ ルックアップで継承されることを示します(E164PSTN)。セカンダリ ルックアップで一致するルート パターンが可変長パターンのため、桁間タイムアウトを待機するように Unified CM が強制されます。中間トランスレーション パターンが固定長のトランスレーション パターンである場合は、これ以上の数字によって中間トランスレーション パターンが一致しない状態になるため、以降の数字をセカンダリ ルックアップで待機してもあまり意味を成しません。したがって、固定長のトランスレーション パターンに対しては、セカンダリ ルックアップでの桁間タイムアウト処理を変更することが適切です。そのためには、トランスレーション パターンのオプション [後続のホップで番号間タイムアウトを待機しない(Do Not Wait For Interdigit Timeout On Subsequent Hops)] を設定する必要があります。このオプションが設定されている場合、トランスレーション パターンに一致すると、Unified CM はそれ以上の数字を待機せず、中間トランスレーション パターンで定義された CSS によって識別されたパターンに対して、変換された着信者番号を照合します。原則として、[後続のホップで番号間タイムアウトを待機しない(Do Not Wait For Interdigit Timeout On Subsequent Hops)] はすべての固定長トランスレーション パターンで有効にする必要があります。
[後続のホップで番号間タイムアウトを待機しない(Do Not Wait For Interdigit Timeout On Subsequent Hops)] オプションのその他の一般的な使用例は、桁間タイムアウトを回避するために番号収集を終了させる特殊キーを使用する、ダイヤリング正規化トランスレーション パターンのセカンダリ ルックアップです。たとえば、米国ダイヤル プランで終了文字 # を持つ国際間宛先を照合するダイヤリング正規化トランスレーション パターン(9011.!# など)は、可変長国際ダイヤリングと一致することができ、ユーザは # を押すことでダイヤリングを終了することができます。このトランスレーション パターンのセカンダリ ルックアップは通常、\+[^1]! などの可変長ルート パターンで一致し、このセカンダリ ルックアップの一致でも番号分析が行われ、追加の番号が待機されます。この場合も、このタイムアウトを避けるための最も簡単な方法は、ダイヤリング正規化トランスレーション パターン 9011.!# で [後続のホップで番号間タイムアウトを待機しない(Do Not Wait For Interdigit Timeout On Subsequent Hops)] オプションを設定することです。
発信側トランスフォーメーション パターンを使用すると、発番号のグローバル形式を、ゲートウェイ、トランクなどのルート グループ デバイスに接続されているオフクラスタ ネットワークで必要となるローカル形式に適応させることができます。
着信側トランスフォーメーション パターンを使用すると、着番号のグローバル形式を、ゲートウェイ、トランクなどのルート グループ デバイスに接続されているオフクラスタ ネットワークで必要となるローカル形式に適応させることができます。
(注) 着信側トランスフォーメーション パターンは、電話機に影響を与えません。また、デバイス プールの着信側トランスフォーメーション パターン CSS も、そのパターンが割り当てられている電話機に影響を与えません。
両方のトランスフォーメーション パターン タイプは、一致する発番号または着番号の数値表現で構成されます。使用される構文は、ルート パターン、トランスレーション パターン、ディレクトリ番号などのその他パターンの構文と同じです(図 14-21 を参照)。
変換演算子には、数字破棄命令(ドット前の番号など)、発信側トランスフォーメーション マスク、プレフィックス番号が含まれます。この演算子によって、発信側電話番号表示(Default、Allowed、または Restricted)が制御されます。発信側トランスフォーメーション パターンを設定することで、発信側の外部電話番号マスクを発番号として使用できます。
パーティションおよびコーリング サーチ スペースによって、どの発信側トランスフォーメーション パターンをどのゲートウェイまたはトランクに適用するかどうかが制御されます。ゲートウェイまたはトランクでは、関連するデバイス プールの発信側変換 CSS またはデバイス固有の発信側変換 CSS を優先順位の低い順に使用できます。同じメカニズムを使用して、着信側トランスフォーメーション パターンの適用を制御します。
[Call Routing Information] > [Outbound Calls] の [Gateway Configuration] ページで設定された発信側および着信側トランスフォーメーション パターンは、ゲートウェイに送信される発番号または着番号と、発信側または着信側の番号タイプおよび番号計画に影響します。[着信側の設定(Incoming Calling Party Settings)] で適用される発信側および着信側トランスフォーメーション パターンは、ゲートウェイから送信されるコールに適用されます。
図 14-21 発信側および着信側トランスフォーメーション パターン
図 14-21 は、発信側および着信側トランスフォーメーション パターンを、さまざまな PSTN で PSTN に接続しているゲートウェイの異なるグループに適用する方法を示しています(フランスおよび NANP エリア)。
北米番号計画(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 で適切なプレフィックス番号を設定できます。デバイス プール、ゲートウェイまたはトランク設定では、削除桁数の方法の定義と、発信側トランスフォーメーション パターンに基づいた柔軟な変換が可能なため、サービス パラメータ設定の使用は推奨されません。さらに、番号を削除したり、着番号として指定した番号にプレフィックス番号を付けたりできます。最初に番号削除操作が着信側の番号で実行され、次にその結果の番号にプレフィックス番号が付加されます。たとえば、削除する桁数を 1 に設定し、プレフィックス番号を +33 と設定し、着信側の番号が 01 58 40 58 58 である場合、+33 1 58 40 58 58 となります。
発信側トランスフォーメーション パターンをコールに適用するために使用するコーリング サーチ スペースを各番号タイプに設定できます。コーリング サーチ スペースには、発信側トランスフォーメーション パターンだけが存在するパーティションが保持される必要があります。これによって、厳密に番号タイプに基づくのではなく、発番号の構造に基づいた変更を発番号に適用できます。発信側トランスフォーメーション パターンでは、正規表現を使用して発番号が照合されます。複数の一致項目から選択するには、best-match プロセスが使用され、選択されたパターンの発信側トランスフォーメーションがコールに適用されます。
前のセクションで説明されている着信側の設定と同じで、着信の着呼側の変換も設定できます。これらの着信の着信側トランスフォーメーションによって、コールを実際にルーティングする前に、着信の着呼側の情報を正規化できます。
着信側トランスフォーメーション パターンをコールに適用するために使用するコーリング サーチ スペースを各番号タイプに設定できます。コーリング サーチ スペースには、着信側トランスフォーメーション パターンだけが存在するパーティションが保持される必要があります。これによって、厳密に番号タイプに基づくのではなく、着信者番号の構造に基づいた変更を着信者番号に適用できます。着信側トランスフォーメーション パターンでは、正規表現を使用して着信者番号が照合されます。複数の一致項目から選択するには、best-match プロセスが使用され、選択されたパターンの着信側トランスフォーメーションがコールに適用されます。
ダイヤリング特権は、特定のエンドポイント(電話、ゲートウェイ、または CTI アプリケーションなど)にどのタイプのコールを許可する(または禁止する)かを制御するために設定されます。Unified CM で処理されるすべてのコールは、次の要素の設定で実装されたダイヤリング特権の対象になります。
パーティション は、同様のアクセシビリティを持つディレクトリ番号(DN)またはディレクトリ URI のグループです。 コーリング サーチ スペース は、特定のデバイスからどのパーティションがアクセス可能であるかを指定します。デバイスは、コーリング サーチ スペースに含まれているパーティション内の DN およびディレクトリ URI だけを呼び出すことができます。
図 14-22 に示すように、パーティション内に配置できるすべての項目は、ダイヤリングの対象となるパターンを持っています。このような項目としては、電話回線、ルート パターン、トランスレーション パターン、CTI ルート グループ回線、CTI ポート回線、ボイスメール ポート、および Meet-Me 会議番号があります。逆に、コーリング サーチ スペースを持つ項目は、コールをダイヤルできるすべてのデバイスです。たとえば、電話機、電話回線、ゲートウェイ、アプリケーション(CTI ルート グループまたはボイスメール ポート経由)などです。
図 14-22 パーティションとコーリング サーチ スペース
パーティションに含めることができるダイヤル プラン項目には、IP Phone のディレクトリ番号、ディレクトリ URI、トランスレーション パターン、ルート パターン、CTI ルート ポイント、およびボイスメール ポートがあります。Unified CM におけるコール ルーティングで説明するように、複数の数値のダイヤル プラン項目(ディレクトリ番号、ルート パターンなど)が重複する場合、Unified CM は、ダイヤルされた番号と一致するか、または最も近い(最も固有性の高い一致)項目を選択します。2 つのダイヤル プラン項目が、ダイヤルされたパターンに等しく一致した場合、Unified CM は、コールを発信するデバイスのコーリング サーチ スペース内で最初に表示されているダイヤル プラン項目を選択します。ディレクトリ URI は、常に完全に一致している必要があります。ディレクトリ URI に部分一致の概念はありません。
たとえば、図 14-23 について考えます。ルート パターン 1XXX と 23XX はパーティション A の一部であり、ルート パターン 12XX と 23XX はパーティション B の一部です。発信側デバイスのコーリング サーチ スペースには、パーティション A:パーティション B の順にパーティションがリストされています。このデバイスのユーザが 2345 をダイヤルすると、Unified CM では、パーティション A のルート パターン 23XX を一致項目として選択します。これは、このパターンが発信側デバイスのコーリング サーチ スペースで最初に示されているためです。ただし、ユーザが 1234 をダイヤルした場合には、Unified CM ではパーティション B のルート パターン 12XX を一致項目として選択します。これは、パーティション A の 1XXX よりも一致率が大きいためです。コーリング サーチ スペースに含まれているパーティションの順序は、closest-match ロジックに基づいて均等一致項目が複数あった場合に、競合を解消する要素としてのみ使用されます。
図 14-23 マッチング ロジックにおけるパーティション順序の影響
(注) 均等一致項目が同じパーティションに複数ある場合、Unified CM は、ローカルのダイヤル プラン データベース内で最初にリストされている項目を選択します。ダイヤル プラン データベース内でダイヤル プラン項目がリストされる順序は、設定することができません。したがって、同じパーティション内で均等一致項目が共存しないようにすることを強く推奨します。これはこのような場合に発生するダイヤル プラン ロジックが予測できないからです。
日時に基づいてパーティションをアクティブまたは非アクティブにできます。パーティションをアクティブまたは非アクティブにするには、まず、Unified CM Administration で期間とスケジュールを設定し、次に個々のタイム スケジュールを各パーティションに割り当てます。スケジュールに指定した日時の範囲外では、このパーティションは非アクティブになります。このパーティションに含まれているパターンは、Unified CM コール ルーティング エンジンによってすべて無視されます。この機能の詳細については、時間帯ルーティングを参照してください。
コーリング サーチ スペースは、特定のデバイスからどのパーティションがアクセス可能であるかを指定します。所定のコーリング サーチ スペースが割り当てられるデバイスは、そのコーリング サーチ スペースにリストされているパーティションだけにアクセスできます。そのコーリング サーチ スペース以外のパーティション内の DN またはディレクトリ URI へのダイヤルは失敗します。発信者にはビジー信号が聞こえます。
IP Phone 回線とデバイス(電話機)自体の両方でコーリング サーチ スペースを設定する場合、Unified CM は、この 2 つのコーリング サーチ スペースを図 14-24 に示すように連結し、デバイスのコーリング サーチ スペースの前に、回線のコーリング サーチ スペースを置きます。
図 14-24 IP Phone の回線とデバイスのコーリング サーチ スペース(CCS)の連結
(注) デバイス モビリティを使用しない場合、デバイスのコーリング サーチ スペースは静的となり、デバイスをネットワークの別の場所に移動しても同じままです。デバイス モビリティを有効にした場合、電話機の IP アドレスによって決定されている、ネットワークで電話機が物理的に配置されている場所に基づいて、デバイスのコーリング サーチ スペースを動的に決定できます。詳細については、デバイス モビリティを参照してください。
同じパターンが、2 つのパーティション(回線のコーリング サーチ スペースに含まれているパーティションとデバイスのコーリング サーチ スペースに含まれているパーティション)に指定されている場合、Unified CM は、パーティションの項で説明している規則に従って、パーティションの連結リスト内で最初にリストされているパターン(この場合、回線のコーリング サーチ スペースに関連したパターン)を選択します。
あらゆるコーリング サーチ スペースの最大長は、各パーティション名の区切り文字を含めて、1024 文字です。(たとえば、「partition_1:partition_2:partition_3」という文字列には 35 文字が含まれています)。そのため、コーリング サーチ スペース内のパーティションの最大数は、パーティション名の長さによって異なります。したがって、パーティションとコーリング サーチ スペースを作成するときは、コーリング サーチ スペースに含める予定のパーティション数を基準にして、パーティション名を短くしてください。コーリング サーチ スペースの設定の詳細は、次の Web サイトで入手可能なオンラインの『Cisco Unified Communications Manager Administration Guide』を参照してください。
パーティションまたはコーリング サーチ スペースを設定する前に、すべての DN は、<None> という名前が付いた特別なパーティションに置かれ、すべてのデバイスには、<None> という名前が付いたコーリング サーチ スペースが割り当てられます。カスタム パーティションとコーリング サーチ スペースを作成する場合は、作成するどのコーリング サーチ スペースにも、<None> パーティションが含まれています。一方、<None> コーリング サーチ スペースには、<None> パーティション だけ が入っています。
(注) <None> パーティションに残っているどのダイヤル プラン項目も、コールを発信する任意のデバイスから暗黙的に到達可能です。したがって、予期しない結果を避けるために、<None> パーティションにダイヤル プラン項目を残さないように強く推奨します。
(注) <None> と定義されたままのコーリング サーチ スペースを残さないでください。そのままにしておくと、ダイヤル プランの動作が予測困難になる可能性があります。
発信側および着信側トランスフォーメーション パターンは、パーティションにも配置されます。それらのパーティションは、コーリング サーチ スペース(CSS)に含まれますが、コール特権を制御するためのものではありません。トランスフォーメーション パターンのパーティションの役割は、どの変換をどのゲートウェイ、トランク、または電話機に適用するかを選択することです。発信側トランスフォーメーション パターン CSS に含まれるパーティションには、発信側トランスフォーメーション パターンのみが含まれていなければなりません。同様に、着信側トランスフォーメーション パターン CSS に含まれるパーティションには、着信側トランスフォーメーション パターンのみが含まれていなければなりません。
(注) この機能が電話機によってアクティブになっている場合、Call Forward All 動作は、宛先番号が個々のユーザによって入力されるその他の自動転送動作とは異なります。
自動転送コーリング サーチ スペースを有効にする方法を決定できます。Calling Search Space Activation Policy(コーリング サーチ スペースのアクティベーション ポリシー)によって指定されている、選択可能なオプションは次の 3 つです。
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 オプションを選択した場合、Directory Number Configuration ウィンドウで明示的に設定されている Forward All コーリング サーチ スペースと Forward All のセカンダリ コーリング サーチ スペースによって、不在転送のアクティブ化と自動転送が制御されます。Forward All コーリング サーチ スペースを None に設定した場合、Forward All に対して CSS は設定されません。そのため、パーティションおよびディレクトリ番号に対する不在転送のアクティブ化の試行は失敗します。不在転送のアクティブ化中に、Forward All コーリング サーチ スペースおよび Forward All のセカンダリ コーリング サーチ スペースの変更は発生しません。
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 つのコーリング サーチ スペースが連結され、連結されたコーリング サーチ スペースを使用することで、不在転送宛先として入力されている番号を検証します。
不在転送が電話機によってアクティブになっているときに、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 のリリースによって異なり、予想することは困難です。このため、自動転送コーリング サーチ スペースを設定する場合は、次のベスト プラクティスに従うことを推奨します。
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 パラメータを設定してコールがボイスメールに送信されることを確認します。
グローバル ダイヤル プラン レプリケーション(GDPR)により、独立した Unified CM クラスタはクラスタ間検索サービス(ILS)を使用して URI、+E.164 番号、エンタープライズ番号、+E.164 パターン、エンタープライズ パターン、PSTN フェールオーバー番号などのダイヤル プラン要素を共有できます。Unified CM クラスタからアドバタイズされたすべてのローカル ダイヤル プラン情報は、単一 GDPR カタログの一部としてアドバタイズされます。アドバタイズされたダイヤル プラン要素の到達可能性は、各 GDPR カタログとともにロケーション属性(SIP ルート文字列)をアドバタイズすることで実現されます。
エンタープライズ固有の番号とパターンは、オンネット サイト間の短縮ダイヤルを許可するグローバルなエンタープライズ固有のダイヤリング手順を表します。GDPR を通じて交換されるエンタープライズ固有の番号とパターンは、グローバルに有効である必要があります。E.164 番号付け方式の特性に基づいた +E.164 番号とパターンは、定義上、グローバルに有効です。
マルチ クラスタ環境におけるこのロケーション属性は、GDPR を介して学習した正しいクラスタへの任意の宛先に対するダイレクト コールに使用されます。確定的に SIP 要求をルーティングするためにディレクトリ URI のホスト部分を使用できない場合、ディレクトリ URI にこれを使用することができます。これは、たとえば、<user>@example.com などのフラットな URI スキームを使用する場合です。example.com というホスト部分は、特定の URI をホストするリモート Unified CM クラスタを一意に識別しませんが、適切に選択された SIP ルート文字列は識別します。
Unified CM 内の各 DN に対して、+E.164 代替番号やエンタープライズ代替番号は設定された DN に適用されるマスクに基づいて定義できます。これらの代替番号はローカル パーティションにオプションで追加できます。各代替番号は GDPR を使用してリモート クラスタにアドバタイズされるように個別に設定できます。
Unified CM 内の各 DN に対して、最大 5 つの URI をエイリアスとして定義できます。個別の URI はそれぞれ、GDPR を使用してリモート クラスタにアドバタイズされるように設定できます。
Unified CM 内の各 DN に対して、エンタープライズまたは +E.164 の代替番号を PSTN フェールオーバー番号としてアドバタイズするために選択できます。リモート クラスタで、この PSTN フェールオーバー番号は +E.164 の代替番号、エンタープライズ代替番号または URI へのコールの PSTN フェールオーバーに使用できます。PSTN フェールオーバーは、GDPR が学習した宛先へのコールが [未割り当ての番号(unallocated number)]、[ユーザがビジー(user busy)]、[通常のコールの消去(normal call clearing)]、[問題のある宛先(destination out of order)]、[サービス使用不可(service not available)] 以外の原因コードで失敗するとトリガーされます。PSTN フェールオーバー番号も、コール アドミッション制御に障害が発生した場合には、自動代替ルーティング(AAR)に使用されます。PSTN フェールオーバー番号へのコールの場合、発信側デバイスの AAR CSS は、リモート クラスタで使用されます。
DN の関連情報(ディレクトリ URI、エンタープライズ代替番号、+E.164 代替番号、PSTN フェールオーバー番号)に加えて、GDPR もエンタープライズ パターンと +E.164 パターンのアドバタイズを有効にします。パターンは DN に関連付けられていないため、ワイルドカードを使用して定義できます(固定長および可変長)。エンタープライズおよび +E.164 パターンの PSTN フェールオーバー番号は削除手順およびプレフィックス手順に基づいて定義されます。
GDPR はローカル ルーティング情報のアドバタイズを許可するだけでなく、URI、エンタープライズ パターンおよび +E.164 パターンを含むことのできるインポートされた GDPR カタログをサポートします。インポートされた GDPR カタログごとに、一意のロケーション属性(SIP ルート文字列)がアドバタイズされます。これにより、クラスタはローカル以外の宛先にルーティング情報を挿入できます。
受信側では、GDPR から学習されたすべてのディレクトリ URI は、数字以外の URI へのルーティングでローカル URI の一致が見つからない場合に参照される単一ローカル リポジトリに挿入されます。すべての学習された URI はサービス クラスの観点から同等として扱われます。
これとは異なり、GDPR が学習した数字パターンと番号は情報のタイプに基づいてローカル パーティションに挿入されます。4 つの独立したパーティションは +E.164 代替番号、エンタープライズ代替番号、+E.164 パターンとエンタープライズ パターンに設定できます。学習された情報の各タイプのデフォルト パーティションは、[グローバル学習 E164 番号(Global Learned E164 Numbers)]、[グローバル学習 E164 パターン(Global Learned E164 Patterns)]、[グローバル学習エンタープライズ番号(Global Learned Enterprise Numbers)]、[グローバル学習エンタープライズ パターン(Global Learned Enterprise Patterns)] です。GDPR を介して学習したリモートの宛先にダイヤルする場合、不要な桁間タイムアウトを回避するために、学習した宛先の緊急パターンをクラスごとに設定できます。
シスコでは、パターン 緊急 としてローカル番号分析に挿入される +E.164 番号と固定長 +E.164 パターンを設定することを推奨します。
ディレクトリ URI および GDPR を介して学習した数値の宛先へのコールのルーティング方法については、Unified CM での SIP 要求のルーティングの項を参照してください。
SIP トランクまたは SIP エンドポイントから受信した SIP 要求のルーティングは、特定のルールに従い、ローカルとクラスタ間の両方のルーティング要件が満たされます。SIP 要求に SIP ルート ヘッダーが含まれている場合、Unified CM は図 14-25 に示されているように処理します。
図 14-25 SIP ルート ヘッダー ベースのルーティング
Unified CM は SIP 要求のリクエスト URI を分析する前に、SIP ルート ヘッダー(例:Route: <sip:ucm.example.com;lr>)の有無をチェックします。SIP ルート ヘッダーがなければ、Unified CM は SIP リクエスト URI に基づいて SIP 要求をルーティングします。
1 つ以上の SIP ルート ヘッダーが存在する場合、 [クラスタ完全修飾ドメイン名(Cluster Fully Qualified Domain Name)] (CFQDN)エンタープライズ パラメータが設定されていて、このパラメータの最初の値がワイルドカードでなければ、Unified CM は最初の SIP ルート ヘッダーに含まれている最初のルート ヘッダー値をルーティング対象と見なします。Unified CM は、SIP ルート ヘッダー値に指定されているホスト(上記の例では、ucm.example.com)が [クラスタ完全修飾ドメイン名(Cluster Fully Qualified Domain Name)] エンタープライズ パラメータに指定されている最初のエントリと一致するかどうかをチェックします。一致する場合、Unified CM は最上位の SIP ルート ヘッダーを削除し、リクエスト URI に基づいて要求をルーティングします。
SIP ルート ヘッダーが存在し、最初の SIP ルート ヘッダー値に指定されているホストが [クラスタ完全修飾ドメイン名(Cluster Fully Qualified Domain Name)] エンタープライズ パラメータで指定されている最初のエントリと一致しなければ、Unified CM は要求をルーティングするために、SIP ルート ヘッダー値を設定済み SIP ルート パターンと照合します。このルーティング動作により、Cisco Spark ハイブリッド コール サービス導入環境内の Cisco Expressway-C とその他のエンタープライズ Unified CM クラスタとの間の中継ルーティング エンティティとして、Unified CM SME を使用できるようになります。Cisco Spark ハイブリッド コール サービス導入環境では、コール サービス接続用に設定されたユーザが Cisco Spark アプリケーションで発信したコールの場合、コール レッグが Cisco Collaboration Cloud から発信側ユーザの Unified CM クラスタにフォークされて、発信側ユーザの Cisco Spark リモート デバイスに固定されます。このコール レッグの SIP 要求では、リクエスト URI に、ダイヤルされた宛先が組み込まれ、Cisco Collaboration Cloud によって要求に追加された SIP ルート ヘッダーに、発信側ユーザの Unified CM クラスタのクラスタ完全修飾ドメイン名が組み込まれます。
図 14-26 に、受信 SIP 要求 URI を英数字 URI として扱うか、数値 URI として扱うかを分類するために Unified CM によって使用される意思決定ツリーを示します。
SIP 要求に user=phone タグがある場合、SIP URI は常に数値 SIP URI として解釈されます。user=phone が存在しない場合、発信側デバイス(エンドポイントまたはトランク)の SIP プロファイルのダイヤル文字列解釈の設定に基づいて決定されます。この設定は、Unified CM が数値 SIP URI として受け入れる文字セット(0 ~ 9、*、#、+ およびオプションとして A ~ D)を定義するか、またはディレクトリ URI としての解釈を強制します。
図 14-27 に、Unified CM によって英数字 URI に適用されるルーティング ロジックのフローチャートを示します。
図 14-27 SIP 要求のコール ルーティング ロジック
最初の手順では、発信側デバイスのコーリング サーチ スペースに基づいて SIP 要求のルーティングを試みます。Unified CM は、発信側デバイスのコーリング サーチ スペースによって指定されたパーティションに設定されたすべてのディレクトリ URI に対して SIP URI の完全一致を検索します。一致が見つかった場合、コールは一致したローカル ディレクトリ URI に関連付けられたディレクトリ番号に伝送されます。
一致するローカル ディレクトリ URI が存在しない場合、Unified CM はインポートされた GDPR カタログまたはリモート システムから学習した GDPR カタログで、再び完全一致によって SIP URI を探します。一致が見つかった場合、SIP 要求は GDPR カタログに関連付けられた SIP ルート文字列(ロケーション ID)を照合することによりルーティングされます。この一部として、発信側デバイスのコーリング サーチ スペースによって指定された設定済み SIP ルート パターンに対して、見つかったディレクトリ URI は学習されています。(図 14-28 を参照)。
SIP URI がローカル ディレクトリ URI で一致せず、どの GDPR カタログ内のディレクトリ URI ともマッチしない場合、Unified CM は SIP URI の右側のみと設定済み SIP ルート パターンとの一致に基づいて SIP 要求をルーティングします。この最終手段のルーティングは、ローカルや GDPR に参加する他の呼制御で不明なすべての SIP URI のためのデフォルト ルートを作成するために使用できます。一般的な例は、Cisco Expressway Business-to-Business(B2B)構成要素への SIP ルートです。
図 14-28 に、ダイヤルされたディレクトリ URI が Unified CM によってルーティングされる例を示します。この例では、下の Unified CM クラスタがローカル ディレクトリ URI「carol@cisco.com 」をアドバタイズします。この Unified CM クラスタのすべてのローカル ディレクトリ URI は、SIP ルート文字列「fra.route」のもとにアドバタイズされます。GDPR を介したこの情報交換の一部として、最上部の Unified CM クラスタは学習したディレクトリ URI テーブルに「carol@cisco.com 」から SIP ルート文字列「fra.cisco.com」への関連付けを読み込みました。最上部のクラスタに登録された電話機からディレクトリ URI「carol@cisco.com 」コールがなされた場合、ディレクトリ URI「carol@cisco.com 」のローカル ルックアップは失敗します。「carol@cisco.com 」はローカル ディレクトリ URI ではないからです。ルーティング プロセスの次の手順は、GDPR が学習したテーブルでディレクトリ URI「carol@cisco.com 」を検索することです。この検索では、下部のクラスタから学習した情報を見つけることができ、最上部の発信元クラスタは学習した SIP ルーティング「fra.cisco.com」を使用し、SIP ルート文字列「fra.cisco.com」と発信側デバイスのコーリング サーチ スペースで指定した設定済み SIP ルート パターンのマッチングでルートを探します。SIP ルート パターン「fra.route」が設定され、ルート リストをポイントします。ルートリストは最終的にはターゲット Unified CM クラスタをポイントする SIP トランクに到達します。発信元 Unified CM クラスタは、こうして宛先 Unified CM クラスタにコールをルーティングします。送信された SIP 要求の宛先は「carol@cisco.com 」になります。宛先クラスタでは、図 14-26 に示したのと同じルーティング ロジックが、「carol@cisco.com 」を宛先クラスタ上のすべてのローカル ディレクトリ URI とマッチングし、完全一致が見つかってターゲット デバイスが鳴ります。
上記の例は、SIP ルート文字列のネーム スペースが、ディレクトリ URI のネーム スペースから完全に独立していることを示します。ディレクトリ URI のホスト部分に使用するネーム スペースの構造と何らかの方法で関連する SIP ルート文字列を使用する必要はありません。これによって望ましいルーティング トポロジに基づいて SIP ルート文字列のネーム スペースを最適化することができます。直接 URI のホスト部分との一致に使用する SIP ルート パターンと、SIP ルート文字列に基づいてディレクトリ URI のルーティングを行うために使用される SIP ルート パターンを区別するために、SIP ルート文字列のルート パターンに対して独立したネーム スペースを使用することを強く推奨します(「.route」、「.ils」など)。
上記の例では、基本的に、選択した SIP ルート文字列が個々の呼制御(fra.route、nyc.route)を識別し、学習した SIP ルート文字列に基づいてディレクトリ 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)とともに使用できます。
SIP URI が数値 URI と見なされた場合(図 14-26 を参照)、コールは図 14-29 のフローチャートに従って処理されます。リリース 9.0 以前の Unified CM では、これが SIP 要求の標準ルーティング手順です。
図 14-29 数値 SIP 要求のコール ルーティング ロジック
最初の手順では、SIP URI の右側が Unified CM クラスタのメンバーであるサーバの IP アドレスまたはホスト名であるか、または Unified CM エンタープライズ パラメータに設定されているクラスタの完全修飾ドメイン名(CFQDN)に一致するかを確認します。この場合、URI の左側はローカル数字パターンと見なされ、発信側デバイスのコーリング サーチ スペースを使用してローカル番号分析にある数字のパターンに一致します。
次の手順では、SIP URI の右側が、Unified CM エンタープライズ パラメータに設定されている組織のトップレベルのドメイン(OTLD)に一致するかどうかを確認します。一致する場合、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 が存在しないと仮定すると、最初の 5 つのコールはすぐに失敗し、Unified CM は、設定されている SIP ルート パターンに cisco.com を照合することによって、6 番めのコールをルーティングしようとします。
数値による一致は、ローカルに存在する数字パターンのどのタイプとも一致する可能性があります。これには、ディレクトリ番号とルート パターンおよびその他の通常の数字パターンは含まれませんが、GDPR が学習したすべての数字パターン マッチと一致する可能性があります(+E.164 番号またはパターン、または会社の電話番号またはパターン)。GDPR が学習した宛先が一致した場合、設定された SIP ルート パターンに一致した GDPR 情報の SIP ルート文字列と照合するセカンダリ ルックアップがすぐに行われます。SIP ルート文字列と照合するセカンダリ ルックアップ用に、最初の数値ルックアップに使用するものと同じコーリング サーチ スペースが使用されます。この動作は、関連する SIP ルート文字列をルーティングする SIP ルート パターンへのアクセスを提供しない CSS を定義して、特定の GDPR カタログの一部として学習された情報へのアクセスを制限するために使用できます。
(注) GDPR が学習した宛先に到達できるように、発信側デバイスのコーリング サーチ スペースは GDPR が学習したパターンが存在するパーティションと、GDPR が学習した宛先に関連付けられた SIP ルート文字列に一致する SIP ルート パターンが存在するパーティションを含める必要があります。
この項では、Cisco TelePresence Video Communication Server(VCS)で利用可能なコール ルーティング メカニズムの概要を示します。詳細な説明については、次の URL にある『 Cisco TelePresence Video Communication Server Administrator Guide 』および各種 Cisco VCS の導入ガイドを参照してください。
https://www.cisco.com/en/US/products/ps11337/tsd_products_support_series_home.html
Cisco TelePresence Video Communication Server(VCS)は、H.323 と SIP を使用する通信を可能にし、本質的にこれらのプロトコルでサポートされているアドレッシング方式を可能にします。
IPv4 または IPv6 の IP アドレスを使用してエンドポイントとマルチポイント デバイスを呼び出すことができます。
H.323 ID は H.323 エンドポイントの英数字の識別子です。任意の英数字の文字列を割り当てることができます。エンドポイントに SIP と H.323 の登録が必要な場合(デュアル登録)、このエイリアスは通常、SIP URI に一致します。
E.164 は PSTN と同じ番号設定方式を使用します。これは、H.323 ID とともに H.323(PSTN で使用される番号計画)で設定できるオプションです。
これは、常に ユーザ名 @ ドメイン の形式を取るエイリアスです。
ENUM ダイヤリングでは、そのエンドポイントが異なる形式のエイリアスを使用して登録されていても、E.164 番号(電話番号)にダイヤリングした発信者がエンドポイントに接続できます。
基本的に、SIP URI は E.164 エイリアスを使用して作成できます。エイリアスのユーザ名部分は E.164 番号で、ホスト名部分がドメインになります。SIP を使用してこのタイプの E.164 マッピングを設定すると、エイリアスからユーザの情報が失われます。この場合、適切なエイリアス、 ユーザ名 @ ドメイン で FindMe を設定し、多くの異なるアドレッシング スキームから生じる複雑さを隠します。FindMe エイリアスはアドレッシング方式に関係なく、ダイヤル可能な任意のデバイスに関連付けることができます。
VCS は、ローカルに登録されたエンドポイント、ネイバー システム、およびパブリック インターネットのエンドポイントからコールを受信します。
VCS に登録されているエンドポイント、ゲートウェイ、マルチポイント デバイス、およびコンテンツ サーバは、ローカル ゾーンの一部と見なされます。ローカル ゾーンはサブゾーンにさらに分割されます。デフォルトで存在するものも、管理者が設定するものもあります。
より一般的に言うと、ゾーンは同じダイヤリング動作と帯域幅の設定を共有するエンドポイントの集合です。ゾーンは VCS に対してローカルでもリモートでもかまいません。
ダイヤル可能なエンティティが VCS に登録されていない場合、他の呼制御またはシステムによって管理されるリモート ゾーンで使用可能な場合があります。これらのリモート ゾーンには、ネイバー ゾーン、トラバーサル クライアントおよびトラバーサル サーバ ゾーン、DNS ゾーン、および ENUM ゾーンがあります。
ネイバー ゾーンの概念は、Cisco Unified CM のトランクの概念と似ています。別の VCS、Unified CM サーバまたはクラスタ、サードパーティの呼制御システム、マルチポイント デバイス、またはゲートウェイへの SIP または H.323 トランク側接続です。
DNS ゾーンは DNS サービス(SRV)を使用して検出できるローカル以外の宛先です。トラバーサル クライアントおよびサーバは、VCS Control および VCS Expressway を使用してインターネット経由の通信にアクセスするためのゾーンです。ENUM ゾーンは、ENUM サービスを使用して到達できるローカル以外の宛先です。
VCS のルーティング ロジックの重要な概念が、トランスフォーム(検索前のトランスフォームとも呼ばれます)と検索ルール(検索とも呼ばれます)です。トランスフォームと検索の違いは、検索には宛先のターゲット ゾーンがありますが、トランスフォームはシステム レベルで設定され、単一ゾーンごとの適用ができないことです。
検索とトランスフォームは管理者が設定した優先順位に従って適用され、パターン分析と文字列操作に正規表現を使用します。
検索前のトランスフォームの概念は、Unified CM のトランスレーション パターンに似ていますが、正規表現を使用して英数字のトランスフォームができるという点が異なります。
検索ルールは、Unified CM のルート パターンに似ています。ルート パターンはトランクまたはルート リストに適用されますが、検索ルールにはターゲットとして宛先ゾーンがあります。
検索ルールとトランスフォームの両方に、次の主な特徴があります。
正規表現で複雑な文字列操作が可能ですが、非常に一般的な、シンプルな適用例がいくつかあります。VCS の最も一般的な文字列操作の 1 つは、エイリアスのドメイン部分を追加するか削除することによって発生します。この例を示します。
このシンプルなルールに従って、VCS に到達するダイヤルされたすべての番号が、number@domain に変換されます。この場合、88302 は 88302@cisco.com に変換されます。
検索ルールには、ダイヤリング方式の作成時に役立つ次の特性があります。
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 がコールを受信すると、設定された検索前のトランスフォームがすべて適用されます。検索前のトランスフォームの後は、呼処理言語(CPL)ロジックが適用されます。このポリシーは、高度なルーティング ルール用の CPL スクリプトを使用して設定され、外部ポリシー サーバを含めることができます。ただし、大半のシナリオでは、CPL を使用する必要はありません。
FindMe エイリアスが設定されている場合、次にユーザ ポリシーが適用されます。FindMe ID は 1 つ以上のターゲット エイリアスに解決され、ターゲット エイリアスを正しく見つけるために、もう一度呼処理ロジックが開始されます。
VCS はその後、優先度順に検索ルールを照会することで、エイリアスに一致する式を検索します。検索ルールが新しい宛先(SIP URI またはエイリアス)を返すと、プロセスが再開します。これは、コールが DNS サービス、ENUM サービス、またはポリシー サービスに送信される場合に発生することがあります。
エイリアスがいずれかのゾーン(ローカル ゾーン、ネイバーなど)で見つかるか、ルーティングの宛先がポリシー サービスによって返された場合、VCS はコールの発信を試行します。
一致がない場合は、コールが失敗したことを示すために、VCS はメッセージを返します。
ルーティング ロジックが最長一致に基づく Unified CM に対して、VCS では、ロジックは優先度ベースです。Unified CM でトランスレーション パターンまたはルート パターンの順序を変更しても、ルーティング アルゴリズムの結果は影響を受けませんが、VCS でルールの優先順位を変更すると、ルーティング動作が変わる原因になります。
ここでは、設計ガイダンスと、エンドツーエンドの企業のダイヤル プランを実装する方法の概要を示します。
この項では、グローバル化された番号に基づいて簡素化されたコール ルーティングを実装するために使用されるダイヤル プラン機能について説明します。主に、オフネット コールに対して発信元にかかわらず単一のルーティング構造を使用することによって、ルーティングが簡素化されます。たとえば、異なる国にいる 2 人のユーザは、それぞれのダイヤリング手順に一致するように設定されたサイト固有のルート パターンの代わりに、同じルート パターンを使用して、それぞれのローカル ゲートウェイに対してコールを伝送できます。
このようなグローバル化を実現するためのアーキテクチャ上の主要なアプローチは、次のようにまとめることができます。
コールの入力ではローカライズ化された形式で受け付け、それらをグローバル化します。グローバル化された形式に基づいてコールをルーティングし、宛先で必要とされる形式に従ってコールをローカライズします。
Cisco Unified Communications Manager(Unified CM)には、次のダイヤル プラン グローバル化機能が備えられています。
また、これらの新機能により Unified CM システムで次のことができるようになりました。
ローカル ルート グループでは、発信側のローカル ルート グループ定義に基づいて選択されたゲートウェイへのオフネット コールをルーティングするパターンを作成する機能を提供します。これにより、たとえば、発信側に近いイーグレス ゲートウェイを選択することができます。たとえば、ルート オフネット、特定の国のすべてのサイトに対する国内通話に対して、1 つのパターンを定義できます。すべてのサイトの電話機をこのパターンに一致するように設定できます。このパターンはその後、発信側電話機に関連付けられたローカル ルート グループと、それぞれのローカル ルート グループに設定された電話機のデバイス プール レベルに基づいて、コールをルーティングします。これによって、サイト 1 の電話機がサイト 1 のゲートウェイを介してコールをルーティングできるようにします。一方、サイト 2 の電話機(こちらも同じパターンを使用)はサイト 2 のゲートウェイを介してコールをルーティングします。この機能は、オフネット コールのサイト固有のルーティング設定を簡素化します。
複数のローカル ルート グループの定義により、異なるコール タイプのイーグレス ゲートウェイの選択を差別化することができるため、たとえば、緊急、国内、国際のコール用にデバイス プールごとに異なるイーグレス ゲートウェイを定義することができます。
電話番号には、他の国から宛先に到達するのに必要な国際ダイヤル アクセス コードを表すために、+ 記号を使用できます。たとえば、+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 に設定する必要があります。同じコールがフランスのゲートウェイに対して再ルーティングされた場合、着信者番号を 1 408 526 4000 に変換し、番号タイプを [国際(International)] に設定する必要があります。
着番号を操作し、着信番号の番号タイプを設定することによって、この機能では着番号がオフクラスタ ネットワークで定められる形式に適合するようにします。
同時に、着信の着信側トランスフォーメーションは、コールをルーティングする前に着信の着信側情報を共通のグローバル化形式に正規化できるようにします。Unified CM では、この機能でゲートウェイごとの設定を取り入れたことにより、番号タイプごとのさまざまなプレフィックスを、異なるゲートウェイに入るコールに適用できるようになりました。設定は優先度順にゲートウェイ自体またはゲートウェイのデバイス プールに設定できます。空白のエントリはプレフィックスとして数字が付加されないことを意味します。より優先順位の低い設定から設定を継承するには、エントリを [Default] に設定する必要があります。より複雑な着信側変換には、番号タイプごとの着信側変換コーリング サーチ スペースが使用できます。SIP はタイプされた番号の概念をサポートしないため、SIP ではタイプ [不明(Unknown)] のデバイス プール設定が考慮されます。
デジタル インターフェイス(たとえば、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 をプレフィックスとして付加することにより得られます。
番号の削除は、グローバル化された番号の一部であってはならない着信番号文字列から番号を削除するために必要です。たとえば、オーストリアの一部の ISDN トランクでは国内宛先からのコールの着信の発信者番号には先頭にゼロが付き、+E.164 にグローバル化するにはこのゼロを削除する必要があります。たとえば、ウィーンからのコールは、発信者番号が 01666001234、発信者番号タイプが [国内(National)] で受信することがあります。このコールではオーストリアの国番号(43)が示され、番号にはすでにウィーンのシティ コード(1)が含まれています。この場合の正規化では、1 桁(先頭のゼロ)の削除と、正規化された +E.164 番号 +43 1 666001234 を得るためのプレフィックス +43 の追加が必要です。
Unified CM では、この機能でゲートウェイごとの設定を取り入れたことにより、番号タイプごとのさまざまなプレフィックスを、異なるゲートウェイに入るコールに適用できるようになりました。設定は、優先順位順にゲートウェイ上、ゲートウェイのデバイス プール上、またはクラスタ全体のサービス パラメータ上で設定できます。空白のエントリはプレフィックスとして数字が付加されないことを意味します。より優先順位の低い設定から設定を継承するには、エントリを [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 を推奨)と同じでない場合、[この電話からのコールの発信者 ID(Caller ID for Calls from this Phone)] 発信側変換 CSS を使用してディレクトリ番号を正しくグローバル化することで、発信者情報の適切な処理を実現する必要があります。これは、電話機から +E.164 へのコールの発呼側情報のグローバル化に推奨される方法です。この方法は、トランスレーション パターンの発信側トランスフォーメーションが適用されない URI でダイヤルされたコール フローとも互換性があるためです。
外部ネットワーク(たとえば、PSTN)による Unified Communications システムに送信される着信番号と発信番号は通常、ローカル化されます。番号の形式は、トランクのサービス プロバイダーの設定によって異なります。ゲートウェイが PSTN トランクに接続されると、システム管理者は PSTN サービス プロバイダーに問い合わせて、この特定のトランクで使用される、適切なシグナリング ルールを決定します。トランクからシステムにコールが送信されると、発信者番号と着信者番号についての一部の情報は明示的に、一部の情報は暗黙的に示されます。この情報を使用して、システムはコールのグローバル化された発番号および着番号を生成する必要があります。
着番号のグローバル化は、次の方法のいずれかによって実行できます。
発番号のグローバル化は、着信側の設定を使用して行う必要があります。この設定は、直接ゲートウェイ上で、またはゲートウェイを制御するデバイス プールのいずれかで設定します。
(注) 管理者がプレフィックスを 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 と表示されます。
(注) 一部の新しい電話では、不在コールと受信コールのディレクトリに格納されている発信者番号は、グローバル化された形式のままのため、ディレクトリに格納された番号文字列を手動で編集せずに、ワンタッチでダイヤルできます。その他の電話では、不在コールと受信コールのディレクトリには変換された発信者番号が格納されます。ディレクトリからのワンタッチでのダイヤルによる問題を回避するには、変換された発信者番号と変換されていない発信者番号の形式を両方ともサポートされているダイヤリング手順に合わせる必要があります。特に、一般的な企業のダイヤル プランでは、10 桁のダイヤリングは通常、短縮サイト内ダイヤリングなどのその他のダイヤリング手順とオーバーラップすることなく企業のダイヤリング手順としてサポートすることができないため、国内番号からのコールの発信者情報の 10 桁へのローカリゼーションを使用できません。
(注) 多くの電話機ユーザは PSTN 番号のグローバル化形式に慣れつつあります。それは主に、国境を越える携帯電話が一般に使われているためです。システム管理者は、着信番号をグローバル形式で表示させたい場合は、発信者トランスフォーメーション パターンの設定を控えて、電話機の発信者情報をローカライズすることができます。
コールがゲートウェイに送信されると、発番号は、トランク グループを提供する PSTN サービス プロバイダーの要件に合せる必要があります(このトランク グループにはゲートウェイが接続されています)。発番号トランスフォーメーション パターンは、発信側番号の番号ストリングと番号タイプの変更に使用できます。通常、ゲートウェイの国コードを示す発番号では、+ 記号を削除し、国コードを明示するように変更する必要があります。また、それらを国のプレフィックスに置き換える必要があります。また、発番号の番号タイプを National に変更する必要があります。ゲートウェイが特定のエリア、シティ コードを示すトランク グループに接続されている場合、+ 記号、国コード、ローカル エリア コードの特定の組み合わせは通常、適切なローカル プレフィックスに置き換える必要があります。また、番号タイプは Subscriber にする必要があります。
たとえば、San Francisco のユーザからのコール(+1 415 555 1234)が、最初の選択肢として San Francisco のゲートウェイ、別の選択肢として Chicago のゲートウェイを指定したルーティング リストを介してルーティングされるとします。San Francisco のゲートウェイは 2 つの発信側トランスフォーメーション パターンを使用して設定されます。
コールが San Francisco のゲートウェイに送信されると、発番号は両方の発信側トランスフォーメーション パターンとマッチングされます。ただし、最初のパターンの方がより正確に一致しているため、発番号の処理にはこちらが選択されます。このようにして、変換された番号は 5551234、発信側タイプは Subscriber に設定されます。
ゲートウェイがコールを処理できなかった場合(たとえば、すべてのポートがビジーだった、など)、コールは PSTN に発信するために Chicago のゲートウェイに送信されます。Chicago ゲートウェイは次の 2 つの発信側トランスフォーメーション パターンを使用して設定されます。
コールが Chicago のゲートウェイに送信されると、発番号は 2 番めの発信側トランスフォーメーション パターンのみとマッチングされます。そのため、ゲートウェイに送信される発番号は 4155551234 となり、発番号タイプは National に設定されます。
コールがゲートウェイに送信されると、着番号は、ゲートウェイが接続されているトランク グループを提供する PSTN サービス プロバイダーの要件に合せる必要があります。着番号トランスフォーメーション パターンは、着番号と着番号タイプの変更に使用できます。通常、ゲートウェイの国コードを示す着番号では、+ 記号を削除し、国コードを明示するように変更する必要があります。また、それらを国のプレフィックスに置き換える必要があります。また、着番号の番号タイプを National に変更する必要があります。ゲートウェイが特定のエリア、シティ コードを示すトランク グループに接続されている場合、+ 記号、国コード、ローカル エリア コードの特定の組み合わせは通常、適切なローカル プレフィックスに置き換える必要があります。また、番号タイプは Subscriber にする必要があります。
たとえば、San Francisco のユーザへのコール(+1 415 555 2222)が、最初の選択肢として San Francisco のゲートウェイ、別の選択肢として Chicago のゲートウェイを指定したルーティング リストを介してルーティングされるとします。San Francisco のゲートウェイは 2 つの着信側トランスフォーメーション パターンを使用して設定されます。
コールが San Francisco のゲートウェイに送信されると、着番号は両方の着信側トランスフォーメーション パターンとマッチングされます。ただし、最初のパターンの方がより正確に一致しているため、着番号の処理にはこちらが選択されます。このようにして、変換された番号は 5552222、着信側タイプは Subscriber となります。
ゲートウェイがコールを処理できなかった場合(たとえば、すべてのポートがビジーだった、など)、コールは PSTN に発信するために Chicago のゲートウェイに送信されます。Chicago ゲートウェイは次の 2 つの着信側トランスフォーメーション パターンを使用して設定されます。
コールが Chicago のゲートウェイに送信されると、着番号は 2 番めの着信側トランスフォーメーション パターンのみとマッチングされます。そのため、ゲートウェイに送信される着番号は 4155552222 となり、着番号タイプは National に設定されます。
(注) コールがゲートウェイに発信されると、発信側および着信側トランスフォーメーション パターンが、発信および着信番号にそれぞれ適用されます。
(注) SIP では番号タイプが示されません。そのため、SIP ゲートウェイでは、Unified CM によって設定された着信側または発信側の番号タイプの表示を受信できません。
ユーザ入力を認識するようにシステムを設定し、コールが正しい宛先にルーティングされ、送信されるようにします。コールはさまざまな形式で発信される可能性があるため、システムはそれらの各形式に一致するパターン認識を用意する必要があります。
グローバル化されたダイヤル プラン アプローチのコア ルーティングは、+E.164 パターンのルーティングに基づいているため、このダイヤル プラン アプローチのネイティブ ダイヤリング手順はグローバルな +E.164 ダイヤリングです。
Unified CM のトランスレーション パターンはローカライズされたユーザ入力を電話機からダイヤルされたものとして、Unified Communications システム内のコールのルーティングに使用するグローバル +E.164 形式に変換します。
サイトごとに設定されているコーリング サーチ スペースでは通常、次のことができます。
図 14-30 で、米国のサンプル サイトのローカルなダイヤリング手順を使用してグローバル化された形式のダイヤリングをサポートする方法を示します。
図 14-30 ローカライズおよびグローバル化されたダイヤリング
図 14-30 で、米国の IP Phone ユーザは 9011496100773 をダイヤルし、ドイツの宛先に接続してからコールを解除します。ドイツの着信側は米国のユーザにコール バックし、接続してから、コールを解除します。その後米国のユーザは Received コール ディレクトリに移り、最後の受信コールのエントリ(+49 6100 773)を選択し、[ダイヤル(Dial)] を押します。
この例では、米国のユーザは別々の 2 つのコールを同じ宛先(+496100773)に向けて開始します。最初のコールの場合、米国のダイヤリング手順に合せてローカライズされた宛先番号の形式が使用されます。対応するトランスレーション パターン 9011.! に対してユーザ入力がマッチングされます。変換されると、同じコーリング サーチ スペースがセカンダリ ルックアップ(トランスレーション パターンに設定される [発信側コーリングサーチスペースを使用(Use Originator's Calling Search Space)])に使用され、ルート パターン \+[^1]! がコールのルーティングに使用されます。2 つめのコールの場合、宛先番号のグローバル化された形式が使用され、ルーティング パターン \+[^1]! が直接使用されます。
これらのコール フローを比較すると、このダイヤル プラン アプローチで実装される 2 ステップのルーティング プロセスが明確に示されます。最初にすべてのダイヤリング手順を +E.164 に正規化し、+E.164 パターンに基づいてルーティングします。有効な PSTN アクセス レベルは、コーリング サーチ スペースによって指定された PSTN ルート パターンで定義されます。より詳細なアクセス レベルは、特定のルート パターンを追加することによって実装できます。
パーティション DN のすべてのディレクトリ番号は、オンネット宛先が呼び出され、ダイヤルされたオンネット宛先がパーティション PSTNInternational の可変長のオフネット ルート パターンと重なった場合に、桁間タイムアウトの可能性を回避するために緊急 DN として設定されます。
パーティション SJCtoE164 での最初のトランスレーションでは、サイトのすべてのローカル DID が +1 408 555 1XXX の範囲内であると想定して、4 桁のサイト内ダイヤリングが実装されています。San Jose のサイトのローカル ダイヤリング(9+7)は、同じパーティションの 2 番目のトランスレーション パターンによって、ローカル ダイヤリング手順を +E.164 に再び変換することで実装されています。海外と国内の宛先に対する米国の PSTN ダイヤリング手順のグローバリゼーションを実装するパーティション UStoE164 にも、同じことが当てはまります。
すべてのダイヤリングの正規化トランスレーション パターンには [発信側コーリングサーチスペースを使用(Use Originator's Calling Search Space)] が設定されるため(CSS 継承)、トランスレーション パターンで定義された着信側変換を適用した後は、セカンダリ ルックアップに使用されるコーリング サーチ スペースはアクティブ化コーリング サーチ スペースと同じです。
要求されたサービス クラスを作成する単一のコーリング サーチ スペースは、回線/デバイス コーリング サーチ スペースとして使用できます。エクステンション モビリティやデバイス モビリティなどのモビリティ機能をサポートする配置では、回線コーリング サーチ スペースを使用してユーザがローミング時にサービス クラスを保持できるようにする必要があります。
これで、内線番号が +1 408 555 1234 であるユーザに、他のユーザからコーリング サーチ スペースを使用して到達できるようになります。この例では、次の番号をダイヤルします。
図 14-30 では、サービス クラス「国際」の +E.164 ダイヤリング手順の正規化を作成するすべてのトランスレーション パターンで CSS 継承を使用するため、着信側トランスフォーメーション(+E.164 へのグローバル化)適用後にセカンダリ ルックアップのために CSS のアクティブ化も使用されます。これにより、他のサービス クラスに対して同じダイヤリングの正規化トランスレーション パターンを再使用できるようになります。
図 14-31 に、サービス クラス「国際」に使用されるスキーマと同じスキーマに基づいてサービス クラス「国内」を定義する方法を示します。図 14-30 のこのスキーマとサービス クラス「国際」との比較では、ダイヤリング正規化および PSTN ルート パターンを含むすべてのパーティションが再使用できることが確認できます。実質的に、唯一の違いは、コーリング サーチ スペース SJCNational にパーティション PSTNInternational の国際 PSTN ルート パターンへのアクセスがないことです。
図 14-31 サービス クラス間でのダイヤリングの正規化の共有
サービス クラス「国内」についても、国際ダイヤリング 9011 のローカル手順に対するダイヤリング正規化パターンへのアクセスが必要です。これは、国際オンネット宛先(米国外のパーティション DN のディレクトリ番号)への国際ダイヤリングをサポートする必要があるためです。
「市内」や「社内」などのより制限の厳しいサービス クラスが、不適切な PSTN ルート パターンを保持するパーティションへのアクセスを単に削除する同じスキーマの後に組み込まれています。
前の図で、パーティションおよびコーリング サーチ スペースに使用されている命名規則は、複数のサービス クラス、サイト、およびダイヤリング ドメインをサポートするために複製する必要があるダイヤル プランを特定するのに役立ちます。名前にサイトの指定(たとえば、パーティション名 SJCtoE164 の SJC)が含まれている場合は、すべてのサイトについてこの要素を複製する必要があります。名前にサービス クラスの指定(たとえば、SJCInternational の International)が含まれている場合は、すべてのサービス クラスについてこの要素を複製する必要があります。名前にサイトの指定が含まれていない場合は(たとえば、パーティション USPSTNNational)、同じダイヤリング手順を共有するすべてのサイト(この例では、米国のすべてのサイト)で再利用できます。
パーティション SJCtoE164 で 4 桁ダイヤリングの正規化のトランスレーション パターン 1XXX は CSS 継承を使用しません。代わりに、このトランスレーション パターンはセカンダリ ルックアップのためのコーリング サーチ スペース DN を使用します。これは、ユーザが 1234 とダイヤルし、ディレクトリ番号 \+14085551234 が存在しない場合に、原因「未割り当ての番号」でコールが拒否されるようにするためです。パターン 1XXX で CSS 継承が使用されている場合、コールは代わりにパーティション USPSTNNational のルート パターンと一致した後で PSTN にルーティングされます。PSTN はコールをすぐに拒否するか、着信側ディレクトリ番号がないため、着信コールとして見なされて拒否されるエンタープライズの PSTN ゲートウェイにルーティングするため、最終的に同じ結果になります。どのゲートウェイにおいても、着信コーリング サーチ スペースルーティング ループは通常、内部の宛先のみにアクセスがあり、PSTN の宛先にはアクセスがないことに注意してください。これは、ルーティング ループを遮断し、電話料金の詐欺行為を回避するためです。
未定義 DN へのコールでの同じ PSTN ヘアピニング問題は、CSS 継承を使用したダイヤリングの正規化トランスレーション パターンによって実装される他のダイヤリング手順と、+E.164 ダイヤリングにも発生します。これらのダイヤリング手順に、DN パーティションに対するループ バックへの DN コーリング サーチ スペースを使用するオプションはありません。これは、オンネットの宛先が、単にこれらのダイヤリング手順を介して到達可能になる宛先のサブセットにすぎないためです。
このヘアピニングを回避する必要のある場合、図 14-32 のスキーマを使用できます。ここでは、パーティション E164OnNet がすべてのオンネット宛先の +E.164 プレフィックスに一致する緊急トランスレーション パターンを保持します。DID 範囲が + 1 408 555 1XXX のサイトでは、E164OnNet に緊急トランスレーション パターン \+14085551XXX が存在します。これらのオンネットのインターセプト パターンは、最終的にプロビジョニングされた DN へのアクセスを提供する DN コーリング サーチ スペースにポイントし返します。すべてのダイヤリングの正規化パターン(短縮されたサイト内ダイヤリングのダイヤリング正規化パターンも含む)は CSS 継承を使用します。未定義 DN へのコールはオンネット パターンによってインターセプトされるため、PSTN にルーティングされなくなります。ダイヤルされた DN が DN パーティションにない場合、コールは原因「未割り当ての番号」によって拒否されます。
図 14-32 未定義 DN への PSTN ヘアピニングの回避と非 +E.164 DN のサポート
E164OnNet でのインターセプト パターンの目的としては、+E.164 からディレクトリ番号の形式へのマップがあります。たとえば、DID 範囲が +1 408 555 1XXX のサイトに対して E.164(プラスなし)としてディレクトリ番号を設定する場合、着信側変換「strip pre-dot」(+ を削除)のトランスレーション パターン \+.14085551XXX は、E164OnNet に設定する必要があります。
+E.164 としてディレクトリ番号を設定することを強く推奨しますが、ディレクトリ番号は E.164(プラスなし)などの別のグローバル化形式、簡潔な企業の番号付けスキーム、または米国の 10 桁で設定することもできます。+E.164 としてディレクトリ番号を設定しない場合、グローバル化された発信者 ID 用に、追加の番号の正規化を設定する必要があります。また、CTI アプリケーション(たとえば、アテンダント コンソール アプリケーション)によっては、設定されたディレクトリ番号がグローバル ディレクトリに格納されている形式に一致しない場合、追加の番号の正規化が必要になる場合があります。
+E.164 DN が使用され、未定義の DN へのオンネット コールの稀なヘアピニングがクリティカルであると見なされない場合、パーティション E.164OnNet にオンネット DN のリストを維持するための取り組みは避け、図 14-30 と図 14-31 に示す簡素化されたダイヤル プラン アプローチを導入する必要があります。
緊急サービスへのアクセスは、すべてのユーザに許可する必要があります。そのためには、緊急番号ルート パターンのパーティションを各コーリング サーチ スペースに追加するか、デバイスレベルのコーリング サーチ スペースを介した緊急番号ルート パターンへのアクセスを有効にします。デバイス コーリング サーチ スペース経由の緊急番号へのアクセスが許可されている場合は、ローミング シナリオ(たとえば、エクステンション モビリティ)において、ユーザは訪問したサイトのダイヤリング手順を使用して、緊急サービスをダイヤルする必要があります。一方、回線コーリング サーチ スペース経由の緊急番号へのアクセスの場合、ユーザはホーム サイトのダイヤリング手順を使用して緊急サービスをダイヤルできます。この違いが明らかに重要になるのは、ホーム サイトと訪問したサイトで緊急サービスのダイヤリング手順が異なる場合のみです。たとえば、欧州のユーザ(緊急番号 112)が米国の電話機(緊急番号 911)にログインする場合などです。
通常、推奨される方式は、発信側デバイスの物理的な場所にローカルな緊急番号で、緊急通話サービスを提供することです。これによって緊急番号と他のダイヤリング手順との間でオーバーラップが発生する場合がありますが(たとえば、短縮ダイヤリングが 9XXX のサイトから米国の電話機にログインした米国以外のユーザのための 9 で始まる 4 桁のサイト内ダイヤリングと、911)、少なくとも、指定された場所の電話機は、いつでも、別の緊急番号を使用する地域のリモート ユーザがログインしているかどうかに依存せずに、現地の慣習的な緊急ダイヤリングを使用して緊急通話を発信できることが保証されます。
新しいグローバリゼーション機能により有効になったダイヤル プラン デザイン アプローチの利点は、次のとおりです。
– Emergency Responder サイト固有のフェールオーバー
– Call Forward Unregistered(CFUR)
– Cisco Jabber などのソフト クライアントからの E.164 番号のクリックツーダイヤル
– ローミング中のエクステンション モビリティ ユーザまたはローミング デバイスから発信されたスピード ダイヤルの適合コール ルーティング
– 電話機ディレクトリ エントリ(デュアルモードの電話機を含む)からのワンタッチ ダイヤリング
– IP Phone ディレクトリの Missed Calls および Received Calls リストからのワンタッチ ダイヤリング
自動代替ルーティング(AAR)宛先マスクがグローバル化された形式に入力されている場合、およびすべての AAR CSS がグローバル化された形式で宛先にコールをルーティングできる場合、システム管理者は AAR グループを設定できます。それは、この機能が、特定の宛先に到達するために、発信電話機の PSTN アクセスの地域要件に基づいてどの数字をプレフィックスとして付加するかを決定する唯一の機能であるためです。プレフィックス番号が設定されていない単一の AAR グループはプロビジョニングしたすべてのデバイスに対して使用できます。
(注) AAR を有効にするには、着信側ディレクトリ番号がグローバル化された形式ですでに設定されている場合でも、着信先で AAR マスクまたは外部電話番号マスクをグローバル化された形式で設定する必要があります。AAR は AAR マスクまたは外部電話のマスクが設定されている場合にだけアクティブになります。
さらに、ほとんどの場合、この AAR CSS の唯一の機能では、コールを発信電話機と同じ場所にあるゲートウェイにルーティングします。そのため、標準ローカル ルート グループを含むルーティング リストを指す 1 つだけのルート パターン(\+!)を使用して設定できます。この 1 つのルーティング パターンを使用してルーティングされるコールは常に発信エンドポイントに関連付けられたローカル ルート グループを介してルーティングされるため、どのリージョン、どの国にいるとしても、すべてのサイトのすべての電話でこの 1 つの AAR CSS を使用できます。
Cisco Emergency Responder へのコールのルーティングは通常、911 CTI ルート ポイントをプライマリ Emergency Responder サーバに接続し、また 912 CTI ルート ポイントをバックアップ Emergency Responder サーバに接続するように設定することによって行われます。
どちらの Emergency Responder サーバも利用できない場合、911 コールは、PSTN が発信側電話機と同じ場所にあるゲートウェイに発信されるように指示できます。設定は次のようにします。
どちらの CTI ルート ポイントも登録解除された場合、911 へのコールは、発信電話機のデバイス プールで決定されたとおりにローカル ルート グループに転送されます。デバイス モビリティが設定されている場合、ローミング電話機は訪問したサイトのデバイス プールと関連付けられます。このため訪問したサイトのローカル ルート グループと関連付けられます。
Call Forward Unregistered 機能によって処理されるコールが、発信側電話機と同じ場所にあるゲートウェイを使用するようにするには、電話機の CFUR 宛先を、PSTN 番号のグローバル化された+ 形式を使用して設定します。CFUR CSS は、標準ローカル ルート グループを含むルート リストを指す 1 つのルート パターン(\+!)のみを使用して設定できます。この 1 つのルーティング パターンを使用してルーティングされるコールは常に発信エンドポイントに関連付けられたローカル ルート グループを介してルーティングされるため、どのリージョン、どの国にいるとしても、すべてのサイトのすべての電話で同じ CSS を使用できます。
PSTN 接続料金を低くするため、システム管理者は、IP ネットワークを使用してオフネットの宛先にコールをルーティングし、PSTN への出口点を着信番号のできるだけ近くにします。同時に、コールの優先 TEHO ルートが使用できない場合、発信電話のローカル ゲートウェイを使用してコールを PSTN に送信する必要がある場合もあります。これは、特定の番号タイプの TEHO ルーティングに参加しているすべての電話で、特定の宛先番号に一致するルート パターンと一致するように設定し、その番号が最初のエントリとして、選択した TEHO 出口ゲートウェイを含むルート リストを、2 番めのエントリとして標準ローカル ルート グループを指すように設定することによって実現できます。
+E.164 の代替番号とエンタープライズ代替番号はマスクを使用してディレクトリ番号に定義され、ローカル番号分析に挿入されて、リモート呼制御にアドバタイズされます。ローカル番号分析への挿入とリモート呼制御へのアドバタイズは個別に有効化できるオプションです。番号をローカル番号分析に挿入し、リモート呼制御にアドバタイズするか、リモート呼制御の PSTN フェールオーバー番号として使用する必要がある場合にのみ、+E.164 またはエンタープライズ代替番号を定義する必要があります。
ローカル番号分析にエンタープライズまたは +E.164 の代替番号を挿入することによって、実質的にディレクトリ番号へのダイヤリングの代替手段を作成します。サイト SJC のディレクトリ番号 \+14085551234 に対しては、マスク 1XXX を使用してパーティション SJCToE164 のエンタープライズ代替番号を定義することもできます。これは、このパーティションでローカル パターン 1234 を作成します。サイトのすべての DN に対して同じエンタープライズ代替番号方式を使用して、SJC は、図 14-30 と図 14-31 に示す 4 桁のサイト内ダイヤリング トランスレーション パターン 1XXX の削除を実質的に許可します。このスキーマは、ローカル サイトだけで有効なエンタープライズ代替番号が曖昧さを避けるためにサイト固有のパーティションに挿入されるため、複数のサイトに拡張できます(たとえば、 表 14-4 を参照)。
|
|
|
|
---|---|---|---|
ディレクトリ番号 +14085551234 および +12215551234 に対し、 表 14-4 に示す設定を使用してまったく同じエンタープライズ代替番号 1234 が作成されますが、サイトの特性が維持されるように、それぞれ異なるパーティション内にあります。
表 14-4 のスキーマは、ローカルの番号分析に追加された GDPR エンタープライズ代替番号が、このダイヤリング手順のダイヤリングの正規化トランスレーション パターンを追加せずに、どのように短縮されたサイト内ダイヤリングの実行に使用できるかを示していますが、ローカル サイトでだけ有効なエンタープライズ代替番号は GDPR にはアドバタイズされません。受信するクラスタでは、重複する(および同一の可能性のある)エンタープライズ代替番号は、ルーティングに曖昧さを生じるため学習する必要があります。
(注) シスコは GDPR でグローバルに有効なエンタープライズ代替番号だけをアドバタイズすることを推奨します。通常、これらのエンタープライズ代替番号は企業の短縮オンネット番号付けプランに沿っています。
表 14-5 は、アクセス コードとして 8 と 2 桁のサイト番号を使用する企業の短縮オンネット番号プランに基づいて、潜在的なエンタープライズ代替番号スキーマを示します。
|
|
|
|
---|---|---|---|
これらのエンタープライズ代替番号はグローバルで有効になったため、すべての市内電話番号に対する短縮サイト間のダイヤリング手順を実行する DN のパーティションに簡単に追加できます。ダイヤリングの正規化トランスレーション パターンに基づいて同等に短縮サイト間オンネット ダイヤリング手順を実行するための従来のアプローチを図 14-33 に示します。
図 14-33 短縮されたサイト内のオンネット ダイヤリングの正規化トランスレーション パターン
(エンタープライズ代替番号をローカル番号分析に追加するか、ダイヤリングの正規化を使用する)どちらのスキームも同等のユーザ エクスペリエンスを実装します。唯一の違いは、ダイヤリングの正規化パターンでは、このオーバーレイ ダイヤリング手順を使用してダイヤルされた未定義番号へのコールは PSTN にルーティングされてから、ヘアピンし返されることです。一方で、ローカル番号分析に各電話番号の明示的なエンタープライズ代替番号を追加すると、ローカル ダイヤル プランのトラブルシューティングをより複雑にする可能性のあるローカル ダイヤル プランを大幅に拡大します。
エンタープライズ代替番号と同様に、+E.164 代替番号も電話番号をマスキングすることによって定義されます。+E.164 DN の +E.164 代替番号を定義するには、マスクを単に空のままにしておくことができます。+E.164 DN の +E.164 代替番号はローカルのダイヤル プランに追加すべきではありませんが、リモート呼制御に +E.164 代替番号または +E.164 PSTN フェールオーバー番号をアドバタイズできる必要があります。
ダイヤリングの正規化トランスレーション パターンを使用して、各電話番号に対するエンタープライズ代替番号を定義する代わりに、短縮されたオンネットのダイヤリング手順を実行することは、より少ないパターンが実際に番号分析に追加されるため、番号分析の複雑さが軽減されます。同様に、ディレクトリごとの個々の代替番号の代わりに、+E.164 とエンタープライズ代替パターンをアドバタイズすることによって、アドバタイズされたダイヤル プラン要素の数を最小限にし、GDPR からアドバタイズされた情報をインポートするリモート呼制御のダイヤル プランの複雑さを軽減します。+E.164 とエンタープライズ パターンの形式でサマリーだけをアドバタイズすることを強くお勧めします。
GDPR からダイヤル プラン情報を学習する呼制御は、タイプによって異なるパーティションに学習された情報を挿入できます(+E.164 代替番号、エンタープライズ代替番号、+E.164 パターン、エンタープライズ パターン)。必要なサービス クラスを実行するためにこのタイプ ベースの差別化が必要ない場合、GDPR から学習したすべての数値のダイヤル プラン情報は、リモート オンネットの宛先にアクセスできるサービス クラスを実行するすべてのコーリング サーチ スペースに追加される単一のパーティションに送信できます(図 14-33 に示すオンネットのパーティションなど)。
差別化されたサービス クラスも、GDPR にアドバタイズされる SIP ルート文字列の形式でロケーション情報のルーティング スキーマを作成する SIP ルート パターンへのアクセスの制限に基づいて行うことができます。これにより、アドバタイズされた SIP ルート文字列の到達可能性に基づいて、特定の呼制御または特定のインポートされた GDPR カタログの一部としてアドバタイズされた宛先の到達可能性を制限できます。
Cisco Unified Communications Manager(Cisco Unified CM)は、Cisco TelePresence System C シリーズ、EX シリーズ、Profile シリーズ、SX シリーズのコーデック登録および英数字 URI ダイヤリングをサポートします。このシナリオで、Cisco TelePresence Video Communication Server(VCS)は、2 個の主要な機能を実行できます。
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-34 に、Unified CM と VCS に登録された音声およびビデオ エンドポイント間のエンドツーエンド通信、および VCS Expressway による企業の外部のピアとの通信を可能にする Cisco VSC と Unified CM の相互接続のトポロジ例を示します。
図 14-34 Cisco VCS と Unified CM を相互接続するためのサンプル トポロジ
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-34 を参照してください)。
この場合、エイリアスの正規化は必要ありません。すべてのエンドポイントは +E164 エイリアスと同じ H.323 ID で到達可能です。ただし、Unified CM との間で送受信されるコールは、最終的な宛先にルーティングされる前に操作を必要とします。
H.323 エンドポイントが VCS に登録されている別の H.323 エンドポイントをコールするとき、H.323 ID と同じに設定されている +E.164 番号を使用し(図 14-34 の +14085551001)、コールは正しく発信されます。
ただし、コールが Unified CM に送られるときは、SIP-to-H.323 インターワーキングが発生し、結果としてドメインを追加する検索ルールが必要になります。範囲 +14085551XXX の +E.164 番号がローカル VCS で使用されていると仮定すると、例 14-5 の検索ルールが必要です。
例 14-5 VCS のローカル +E.164 宛先用の検索ルール
内部の範囲をダイヤルする VCS に登録された各 H.323 クライアントは、このルールに一致します。
+E.164 コールが Unified CM から VCS に着信した場合、ダイヤルされたアドレスは次のいずれかの形式になります。
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 の検索ルールによって、\+14085551XXX に一致し、ローカル クライアントに一致しない VCS からのすべての数字のダイヤリングが Unified CM に送信され、Unified CM に送信される SIP URI のホスト部分が「cisco.com」に設定されます。Unified CM での SIP 要求のルーティングの項、特に図 14-29 に記載されているように、Unified CM 内の SIP ルーティング メカニズムに従って、Unified CM が Unified CM で設定された番号の +E.164 ダイヤル プランに従ってこれらの数字の SIP URI のパスを指定するように Unified CM の組織のトップ レベル ドメイン(OTLD)は「cisco.com」に設定されていなければなりません。このルールは、VCS に登録された SIP エンドポイントがある場合、これにも一致します。
B2B 接続を可能にするには、VCS が、B2B 構築ブロックにローカル以外の SIP URI のホスト部分があることで識別されるすべての B2B コールを VCS Expressway にルーティングしなければなりません。例 14-7 の検索ルールは、cisco.com 以外のドメインを持つものすべてに一致し、一致したものを VCS Expressway およびインターネットへ送信することによって、これを実現します。
Unified CM で、VCS でホストされる +E.164 プレフィックスは、特定の +E.164 ルート パターンを Unified CM ダイヤル プランに追加し、適切なルート リストおよびルート グループ設定によってこのルート パターンが VCS へのトランクに対応することを確認することによって、追加されなければなりません。
VCS に登録されたエンドポイントが Unified CM に登録されたエンドポイントと同じ DN 範囲を共有している場合、Unified CM のダイヤル プラン設定は、Unified CM で不明であるローカル プレフィックスのすべての +E.164 番号が VCS にルーティングされることを保証しなければなりません。図 14-35 に、グローバル化されたダイヤル プラン アプローチでこれを実現する方法を示します。
図 14-35 のグローバル化されたダイヤル プランは、Unified CM のグローバル化されたダイヤル プラン アプローチの項で説明したアプローチを使用します。端的に言えば、既知のオンネット +E.164 プレフィックスで一致する、すべてのダイヤリングの正規化のトランスレーション パターンおよび緊急トランスレーション パターンから参照される DN コーリング サーチ スペースは、VCS と共有する +E.164 プレフィックスで一致するルート パターンを含むように拡張しなければなりません。Unified CM のディレクトリ番号と一致しなかったこの範囲のすべての +E.164 パターンは、このルート パターンに一致し、VCS に送信されます。ルーティング ループが発生しないように、VCS から着信するトランクの着信コーリング サーチ スペースは、このルート パターンにアクセスして戻らないようにしてください。
また、Unified CM のダイヤル プランは、Unified CM にとってローカルなディレクトリ URI に対応しない、URI(数字でない)としてダイヤルされたすべてのコールが VCS にルーティングされるようにする必要があります。これを実現する最も簡単な方法は、Unified CM で、適切なルート リストおよびルート グループ設定を通じて VCS へのトランクにも対応する「catch-all」SIP ルート パターン(*.* など)を追加することです。ここでも、ルーティング ループが発生しないように、VCS から着信するトランクの着信コーリング サーチ スペースは、この「catch-all」SIP ルート パターンにアクセスしないようにしてください。
Unified CM のエンドポイントに SIP URI および +E164 番号を使用して到達できる場合、例 14-8 に示すように、VCS から Unified CM に正しくルーティングする別の検索ルールを追加できます。
例 14-8 VCS から Unified CM への URI ダイヤリングの検索ルール
H.323 エンドポイントが、+E.164 エイリアスを使用する代わりに同じ SIP URI 形式の英数字のエイリアスを使用してアドレス指定されている場合、例 14-5 の「To VCS」検索ルールは、例 14-9 のいずれかに置き換えることができます。
例 14-9 H.323 登録エンドポイントの URI ダイヤリングをサポートするように変更された検索ルール「To VCS」
エイリアスがローカル ゾーンにない場合、これはエイリアスではなくローカルであることを意味し、優先度 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 の機能に関連する、ダイヤル プランに関する考慮事項を説明します。
自動代替ルーティング(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 はエクステンション モビリティ機能と共存できません。詳細については、エクステンション モビリティを参照してください。
コールを再ルーティングするには、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 設定全体が大幅に簡素化されるためです。たとえば、パリにある電話機は 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 にコールが発信されます。
宛先番号(国コードが含まれると前提)が元の支店のダイヤル プランによって正常にルーティングされるためには、プレフィックスが必要になる場合があります。また、発信地点が別のエリア コードまたは別の国に配置されている場合、ダイヤルされたストリングの一部として、国際ダイヤル アクセス コード(たとえば、00、011)などの他のプレフィックスが必要になる場合があります。
AAR を設定する場合は、DN を AAR グループ内に配置します。AAR グループのペアごとに、同じ AAR グループ内で発信または終端するコールのプレフィックス番号も含めて、その 2 グループ間のコールで DN に追加するプレフィックス番号を設定できます。
一般的な規則として、複数の DN が各国間で同じダイヤリング構造を共有している場合は、それらの DN を同じ AAR グループに配置します。たとえば、UK 国外にある UK ダイヤル番号のすべての電話機は、9 を PSTN アクセス コードとして使用し、その後に国際アクセス コードの 00 が続きます。フランスおよびベルギーにあるすべての電話機は、0 を PSTN アクセス コードとして使用し、その後に国際アクセス コードの 00 が続きます。NANP にあるすべての電話機は、9 を PSTN アクセス コードとして使用し、その後に国際アクセス コードの 011 が続きます。
|
|
|
|
|
|||
|
|||
|
例 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 ダイヤル プランのメリットがはっきりとわかります。
これらの例で、+E.164 ディレクトリ番号によるダイヤル プランのメリットがはっきりとわかります。特定の AAR グループまたは PSTN プレフィックスを設定する必要がありません。ダイヤルされたオンネット宛先がすでにダイヤル プランのコア ルーティングで使用される形式(+E.164)のため、ダイヤルされたディレクトリ番号を代替コールの PSTN アドレスとして直接使用することができます。
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 に発信されます。
|
|
|
|
|
---|---|---|---|---|
|
||||
|
||||
|
(注) デバイス モビリティを使用しない場合、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 コーリング サーチ スペース設定を大幅に簡素化することできます。これは、+E.164 AAR 宛先マスクまたは +E.164 ディレクトリ番号のいずれかを使用することで実現することができます。単一のパーティションで設定され、単一のルート パターン \+! が含まれ、さらに標準ローカル ルート グループを備えた単一のルート リストを指している単一のコーリング サーチ スペースを使用することで、クラスタ全体のすべてのサイトですべてのコールをルーティングできます。これは、適切なゲートウェイ固有の着信側トランスフォーメーション パターンを利用して、宛先番号のユニバーサル形式を、各サイトでコールが送信されるサービス プロバイダー ネットワークで必要となるローカル形式に適応させます。
(注) オンネット社内コールを強制的に PSTN コールとしてダイヤルする追加のルート パターンを設定した場合は、それらのパターンが AAR 機能のものと一致しないことを確認します。+E.164 ディレクトリ番号によるグローバル化されたダイヤル プランでは、これらの +E.164 ディレクトリ番号を保持するパーティションは、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 が使用されます。これにより、電話機は発信側電話番号表示モード(訪問した場所にある電話機の慣習的表示モード)を継承できます。
デバイス設定ページで設定されているデバイス コーリング サーチ スペースではなく、ローミング デバイス プールのデバイス モビリティ コーリング サーチ スペースが使用されます。たとえば、デバイスが San Francisco から New York にローミングしているとき、New York デバイス プールのデバイス モビリティ コーリング サーチ スペースが、ローミング電話機のデバイス コーリング サーチ スペースとして使用されます。サービス クラスに対して回線/デバイス アプローチを使用している場合、このアプローチは PSTN コールが取るパスを確立し、ローカルな New York ゲートウェイにルーティングします。
デバイス設定ページで設定されている AAR コーリング サーチ スペースではなく、ローミング デバイス プールの AAR モビリティ コーリング サーチ スペースが使用されます。たとえば、デバイスが San Francisco から New York にローミングしているとき、New York デバイス プールの AAR コーリング サーチ スペースが、ローミング電話機の AAR コーリング サーチ スペースとして使用されます。このコーリング サーチ スペースは発信 AAR PSTN コールが取るパスを確立し、ローカルな New York ゲートウェイにルーティングします。
着信 AAR コールの場合、DN のホスト電話機がローミングしているかどうかにかかわらず、DN に割り当てられている AAR グループが保持されます。これにより、AAR 宛先番号に対して確立された到達可能性の特性が保持されます。
発信 AAR コールの場合、発信 DN の AAR グループでは、DN の設定ページで選択された AAR グループではなく、ローミング デバイス プールの AAR グループが使用されます。この AAR グループは、ローミング デバイス上のすべての DN に適用されることに注意してください。たとえば、New York から Paris にローミングするデバイス上のすべての DN(どちらの場所も同じデバイス モビリティ グループであることを前提とする)は、Paris デバイス プールの発信コールに対して設定されている AAR グループを継承します。この AAR グループはローミング デバイス上のすべての DN に割り当てられます。また、ローミング電話機上の DN から行われた AAR コールに対して適切なプレフィックスを付加することを許可します。
デバイスが同一のデバイス モビリティ グループ内をローミングしているとき、Unified CM ではローカル ゲートウェイへの到達にデバイス モビリティ CSS を使用します。ユーザが電話機で Call Forward All を設定している場合、CFA CSS が None に設定されていて、CFA CSS Activation Policy が With Activating Device/Line CSS に設定されていると、次のようになります。
デバイス モビリティの項で、この機能について詳しく説明します。
エクステンション モビリティ機能を使用すると、ユーザが IP Phone にログインしたとき、内線番号、スピード ダイヤル、メッセージ待機インジケータ(MWI)ステータス、コール特権を含めて、そのユーザのプロファイルが自動的にその電話機に適用されるようになります。このメカニズムは、それぞれのエクステンション モビリティ ユーザに関連付けられる、デバイス プロファイルを作成することで成り立っています。デバイス プロファイルは、実質的には仮想 IP Phone であり、1 つまたはそれ以上の回線を設定したり、コール特権やスピード ダイヤルなどを定義したりできます。
IP Phone がログアウト状態になっている(つまり、エクステンション モビリティ ユーザがログインしていない)とき、この IP Phone の特性は、デバイス設定ページと回線設定ページによって決まります。ユーザが IP Phone にログインすると、デバイス設定は変更されませんが、既存の回線設定は Unified CM データベースに保存され、ユーザのデバイス プロファイルの回線設定によって置き換えられます。
エクステンション モビリティの重要な利点の 1 つは、ユーザがどこにいるかにかかわらず、同じ Unified CM クラスタによって制御されている IP Phone にユーザがログインできれば、そのユーザに対して、そのユーザ固有の内線番号で到達できることです。集中型呼処理を使用しているマルチサイト配置に対してエクステンション モビリティを適用すると、地理的に互いに分離している複数のサイトに対して、この機能を展開できます。
ただし、エクステンション モビリティ機能を自動代替ルーティングの項で説明している AAR 機能と組み合わせる場合は、一定の制限事項があります。図 14-36 に示した例について考えます。エクステンション モビリティと AAR を集中型呼処理の Unified CM クラスタに配置していて、San Jose と New York にそれぞれ 1 つのサイトがあります。
この例では、通常、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 つのうち、いずれかのシナリオが発生します。
ヒント ここで説明したようなルーティング ループを防止するには、ゲートウェイ設定ページでコーリング サーチ スペースを設定するときに、必ず内部の宛先のみを含め、同じゲートウェイを含んでいるルート グループやルート リストを指すルート パターンを一切含めないようにします。
この例では、エクステンション モビリティが 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 パラメータの影響を理解するには、次の例について考えてみます。
(注) この説明で必要なパラメータのみを、ここで示しています。
ユーザ Paul は、次のように設定された IP Phone を所有しています。
Paul の DN は、次のように設定されたリモート宛先プロファイル(RDP)に関連付けられています。
再ルーティング コーリング サーチ スペース:P_RDP_Rerouting_CSS
Paul の RDP は、次のように設定されたリモート宛先に関連付けられています。
宛先番号:+1 514 000 9876(これは Paul の携帯電話番号。シングルモードまたはデュアルモードのいずれかの電話機)
Paul または Ringo の DID 番号にかけられた PSTN からのコールは、次のように設定されたゲートウェイによって処理されます。
ユーザ Ringo は、次のように設定された IP Phone を所有しています。
リモート宛先プロファイル(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 トランクからの着信コールにも当てはまります。
企業の 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 と表示されるようにします。
この場合、次のパラメータを使用してトランスフォーメーション パターンを作成します。
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 をプレフィックスとして付加する必要があります)とは異なります。この場合、リモート宛先の形式を企業ダイヤル プランの形式に適合させるために、適用ダイヤル規則を作成する必要があります。
説明:プレフィックス 91 を 514000 で始まる 10 桁の番号に付加するために使用
この例では、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-37 では、同じコール パターン(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-37 の例では、水曜日の午後 3 時にハント パイロット(8000)に着信したコールは、SJC の電話に転送されます。一方、このハント パイロットに 7 月 4 日にコールした人は、別のパターンが 8000 に一致しない限り、ファーストビジー トーンを受信します。
(注) コールのすべての参加者が interior として分類されないと、ポリシーは適用されません。つまり、同じクラスタにある電話機間のコールに論理パーティション ポリシーが適用されることはありません。
(注) ジオロケーションは、Unified CM で設定するコール アドミッション制御用のロケーションや、デバイス モビリティに使用される物理ロケーションと混同されることはありません。
|
|
---|---|
Unified CM は、エンドポイントを interior または border に分類します。この分類は固定されており、システム管理者が変更することはできません。
(RFC) 4119 規格には、ジオロケーションの基本情報が記載されています。ジオロケーションには、次のオブジェクトによって指定される住所形式が使用されます。
(注) 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、および B と C のジオロケーション ID をチェックし、事前設定済みポリシーとの一致を確認します。ポリシーの一致によって処理が拒否された場合、新しいコール レッグは確立できません。
(注) Unified CM のデフォルト ポリシーは拒否です。つまり、コール レッグを許可するように明示的にポリシーを設定していなければ、コール レッグは拒否されます。
この例では、バンガロールの Interior デバイスがオタワの Border デバイスに接続できるように明示的にポリシーを設定していない限り、コール レッグは拒否されます。