Cisco Unified Communications Manager 機能およびサービスガイド リリース 8.6(1)

ローカル ルート グループ

管理者は、新しいルート グループをルート リストに追加すると、選択対象であるすべての使用可能なルート グループを [ルートリストの設定(Route List Configuration)] ウィンドウで確認できます。このリストには、[標準ローカルルートグループ(Standard Local Route Group)] と名付けられた特別なルート グループが、リストの最初のメンバとして含まれています。このローカル ルート グループは、仮想ローカル ルート グループを示します。

ローカル ルート グループは、プロビジョニングされたルート グループには静的にバインドされません。ローカル ルート グループは [ルートグループの検索と一覧表示(Find and List Route Groups)] ウィンドウには表示されないため、削除や変更を行うことはできません。ただし、ローカル ルート グループを任意のルート リストに追加することは可能です。この追加が行われると、ローカル ルート グループはプロビジョニングされたルート グループのプレースホルダとして機能します。プロビジョニングされたルート グループはその後、コールの設定時にローカル ルート グループに動的にバインドされます。

ローカル ルート グループをルート リストに追加すると、後でそのローカル ルート グループをリストから削除したり、またはプロビジョニングされた任意のルート グループと同様に、リスト内における検索順序の場所を変更したりできるようになります。

追加情報

「関連項目」を参照してください。

コール中に、プロビジョニングされたルート グループをローカル ルート グループにバインド

プロビジョニングされたルート グループのローカル ルート グループへのバインドをコール設定時まで保留すると、プロビジョニングされた目的のルート グループが、コールを発信しているデバイスに対してローカルなグループになります。このため、ロケーション X にあるデバイスはロケーション X のPSTN のゲートウェイを含むプロビジョニングされたルート グループを使用し、ロケーション Y にあるデバイスはロケーション Y の PSTN のゲートウェイに関する別のプロビジョニングされたグループを使用します。

システムの各デバイスがそのローカル ルート グループを認識するためにプロビジョニングされているということを、確認する必要があります。何千ものデバイスが存在する可能性があるので、各デバイスの設定ウィンドウでこの情報を特定せずにすむよう、Cisco Unified Communications Manager の管理ページを使用して、デバイスのデバイス プール内で情報を特定できます。これは、デバイス プールが共通のサイト特有の情報を指定するためです。

[デバイスプール設定(Device Pool Configuration)] ウィンドウの [ローカルルートグループ(Local Route Group)] フィールドには、使用可能なすべての（プロビジョニングされた）ルート グループを一覧表示するドロップダウン リスト ボックスがあります。このリストには、特別な標準ローカル ルート グループの名前は表示されません（デバイス プールでは、プロビジョニングされたルート グループだけが設定されるためです）。ただし、このリストには、最初の（デフォルトの）選択肢を示す <NONE> という特別な名前が表示されます。バインドを必要としない場合は、<NONE> を選択します。

デフォルトの値である <NONE> がデバイス プールに対して選択されている場合、ローカル ルート グループである標準ローカル ルート グループを含むルート リストを使用するコールは常に、標準ローカル ルート グループがリストに存在しないかのようにルーティングされます。

このメカニズムに基づき、特別な標準ローカル ルート グループを含むルート リスト上のデバイスから発信されるコールは、次のように動作します。

1. ルート リストのアルゴリズムによって、未使用のトランクが見つかるまで、含まれているルート グループのリストが指定の順序で検索されます （以前および現在の実装に違いはありません）。

2. 検索によって特別な標準ローカル ルート グループが検出されると、このルート グループは自動的に、発信側デバイスに対してプロビジョニングされているローカル ルート グループの名前に置換されます。ただし、検索結果が次のいずれかである場合は例外です。

• プロビジョニングされたルート グループが <NONE> を示している場合、標準ローカル ルート グループは完全にスキップされます。

• 標準ローカル ルート グループがこのようにスキップされることによって検索が終了すると（つまり、標準ローカル ルート グループがルート リスト内の最後または唯一のルート グループとなった場合）、ルーティングは中断し、ユーザはリオーダー音（または同等の通知）を受信します。

追加情報

「関連項目」を参照してください。

ローカル ルート グループでのルーティング

ローカル ルート グループのマッピングによって、Cisco Unified Communications Manager はゲートウェイをサービスのように扱うことができます。お客様はこのソリューションによって、ルート プランをプロビジョニングおよびメンテナンスするための労力を省けるという利点が得られます。

例

この例では、図 31-1 に示すように、5 つの管理対象サイトを持つ集中型コール モデルを想定しています。以降の項では、このコール モデルを使用して、ローカル ルート グループ機能に関する次の 2 種類の現象を示します。

• 各サイトがオフネット コールをローカル ゲートウェイにルーティングする必要がある、単純なローカル ルーティングのケース。

• より複雑なテール エンド ホップ オフ（TEHO）のケース。

図 31-1 集中型モデルでのローカル オフネット アクセスの管理

ローカル ルート グループ機能を使用する Cisco Unified Communications Manager の構成では、目的の接続先に必ず到達するよう、着信側トランスフォーメーションによってコールされた番号を正規化する必要があります。

追加情報

「関連項目」を参照してください。

単純なローカル ルーティング

単純なローカル ルーティングは、各サイトがそのローカル ゲートウェイにオフネット コールをルーティングすることが必要なケースに対応します。ルート パターンおよびルート リストのプロビジョニングについては、N 個のルート パターンおよびルート リストを設定する手間を、1 個のルート パターンおよびルート リストだけの設定に減らすことができます。

このケースではさらに、ある特定のサイトをホームとしている電話機すべてが、そのサイトに固有の単一の Calling Search Space（CSS; コーリング サーチ スペース）に属していると仮定します。たとえば、ボールダー サイトにある電話機は、CSS-Bldr コーリング サーチ スペースに属しています。その他のサイトも同様にそれぞれ CSS に属しています。図 31-2 は、ローカル ルート グループ機能を使用しない状態で、このシステムで発生し得るプロビジョニングを示しています。つまり、9 をダイヤルし、続けて 7 桁、10 桁、または 11 桁のパターンをダイヤルしてオフネット コールを発信する場合には、電話機はサイトに関係なく、常にそのローカル ゲートウェイを優先します。さらに多くのサイトが追加されると、それぞれのカラムは新しいエントリ（行）を含める必要があります。N 個のサイトが存在する場合は、N 個のルート リスト、ルート パターン、パーティション、およびコーリング サーチ スペースが必要となります。

図 31-2 ローカル ルート グループを使用しないローカル オフネット アクセスのプロビジョニング

同じ実装でローカル ルート グループ機能を使用すると、サイトの数に関係なく、単一のルート リスト、パーティション、ルート パターン、および CSS を設定できるようになります。図 31-3 を参照してください。

図 31-3 ローカル ルート グループを使用するローカル オフネット アクセスのプロビジョニング

この場合、次の設定が適用されます。

• すべての電話機が、単一の CSS-System コーリング サーチ スペース、および単一の P-System パーティションに属する。

• 所定のサイトのすべての電話機が、そのサイトに固有である 1 つのデバイス プールに属する。

• 各デバイス プールの [ローカルルートグループ(Local Route Group)] フィールドが、そのサイトの特定のルート グループを識別する。この例では、ボールダーは RG-Bldr、リチャードソンは RG-Rch となる。

このため、このケースでのルート リスト、ルート パターン、パーティション、およびコーリング サーチ スペースは、それぞれ N 個から 1 個に減少します。ゲートウェイ、ルート グループ、およびデバイス プールの数は、N 個のサイトに対して N 個のままです。

すべてのサイトから 9.@ パターンにアクセスするため、新しいパーティション P_System、および新しいコーリング サーチ スペース CSS_System が追加されます。コーリング サーチ スペース CSS_Boulder は、他のサイトの CSS と同様に、P_Boulder および P_System も含めることができます。

追加情報

「関連項目」を参照してください。

テール エンド ホップ オフ

テール エンド ホップ オフ（TEHO）とは、VoIP ネットワークを越えて長距離電話をルーティングし、それらのコールをリモートのゲートウェイで市内電話として公衆電話交換網（PSTN）にドロップすることを指します。TEHO を使用する場合、N ² 個のエンティティを設定する代わりに N 個のエンティティを設定するだけでよく、設定上の複雑さを軽減できます。TEHO に関しては、次の状態を前提としています。

• 各サイトには、他の N-1 個の各サイトに対する個別のルート パターン、およびルート リストが存在する。

• 所定のサイト S に関して、別の（リモート）サイトに対する N-1 個の各ルート リストは、その別サイトにとってローカルな 1 つまたは複数のゲートウェイのルート グループを第 1 優先として持ち、次に、S にとってローカルなルート グループを第 2 優先として持つ。したがって、十分なトランキング リソースが使用可能で、第 1 優先となり得る場合、長距離電話はリモート サイトでゲートウェイを使用してオフネットとなるため、通話料金の課金対象になりません。十分なトランキング リソースが使用可能でない場合、コールはデフォルトのローカル ゲートウェイに戻り、通話料金の課金対象となります。

この場合もやはり、Cisco Unified Communications Manager は、すべてのサイトに対して同じルーティング ポリシーを持ちます。第 2 優先項目として、サイトのローカル PSTN でコールをルーティングすると（システムがリモートの PSTN でコールを市内電話としてドロップしなかった場合）、お客様はサイトごとにすべてのルーティング情報に関する別個のインスタンスをプロビジョニングするように強制されます。図 31-4 を参照してください （この図では、一部のサイトの構成を示しています）。各サイトには、他の N-1 個の各サイトに対するルート パターンおよびルート リストの固有のセット、およびリモートのアクセス コードがカバーしていないその他すべてのコールに関する汎用のローカル ルート リストがあります。この要件は、一般的なケースに関する N*(N-1)+N 個、つまり N ² 個のルート リストおよびルート パターンを必要とします。

図 31-4 ローカル ルート グループを使用しない TEHO のプロビジョニング

ローカル ルート グループ機能を使用する場合、リモート サイトに必要な N*(N-1) 個のルート パターンおよびルート リストは N 個に減少し、N 個のローカル ルート パターンおよびローカル ルート リストは 1 個に減少します。全体的には図 31-5 のように、ルート リストおよびルート パターンの合計数は N ² から N+1 に減少し、コーリング サーチ スペースおよびパーティションは N 個から 1 個に減少します。

図 31-5 ローカル ルート グループを使用する TEHO のプロビジョニング

図 31-5 では、重要なエレメントが、各ルート リストの 2 番目の選択肢として 標準ローカル ルート グループ を使用していることに注目してください。発信側デバイスのデバイス プールの設定によって、特定のコール中に使用される、実際のプロビジョニングされたルート グループが動的に決定されます。

追加情報

「関連項目」を参照してください。

着信側トランスフォーメーション

エンタープライズ番号とルート グループおよびゲートウェイとの間で疎結合が発生している最中には、ルート グループおよびゲートウェイと PSTN が予想するパターンとの間に極度の密結合が発生します。選択されたゲートウェイが 7 桁のダイヤリング ロケーションに存在する場合、PSTN は 7 桁を予想します。選択されたゲートウェイが 10 桁のロケーションに存在する場合は、PSTN は 10 桁を予想して市内番号にアクセスします。

例 1

コールがダラスから発信された場合、その着信番号は 9.5551212 を示します。ダラスのローカル ゲートウェイがビジーまたはアクセス不能である場合は、サンノゼのゲートウェイが選択されることを想定して、9.5551212 を、サンノゼのゲートウェイがダイヤルアウトする 1 214 555 1212 に変換する必要があります。

ローカル ルート グループのケースに関する同じ例では、コールがダラスから発信されます。着信番号は 9.5551212 を示しているため、システムは次のアクションを実行します。

1. 発信者がダイヤルしたとおりの番号を使用して、PreDot を破棄し、プレフィックス +1 214 を挿入します。

2. コールの番号を、グローバルに一意である E.164 ストリング（+1 214 555 1212）に変換します。

サンノゼのゲートウェイが選択された場合、システムはグローバル ストリングである +1 214 555 1212 を 1 214 555 1212 に変換します。ダラスのゲートウェイが選択された場合、システムはグローバル ストリングを 214 555 1212 に変換します。

この例の図については、図 31-6 を参照してください。

図 31-6 コールされた番号の変換

例 2

コールが RTP から発信された場合、その着信番号は 5551212 を示します。RTP のローカル ゲートウェイがビジーまたはアクセス不能である場合は、サンノゼのゲートウェイが選択されることを想定して、5551212 を、サンノゼのゲートウェイがダイヤルアウトする 1 919 555 1212 に変換する必要があります。

ローカル ルート グループのケースに関する同じ例では、コールが RTP から発信されます。着信番号は 9.5551212 を示しているため、システムは次のアクションを実行します。

1. ダイヤルしたとおりの番号を使用して、PreDot を破棄し、プレフィックス 91919 を挿入します。

2. 着信番号を、グローバルなダイヤリング ストリング（9 1 919 555 1212）に変換します。

サンノゼのゲートウェイが選択された場合、システムはグローバル ストリングである 91 919 555 1212 を 1 919 555 1212 に変換します。RTP ゲートウェイが選択された場合、システムはグローバル ストリングを 555 1212 に変換します。

追加情報

着信側トランスフォーメーションの詳細については、『 Cisco Unified Communications Manager システム ガイド 』の 「ルート プランの概要」 にあるの項を参照してください。

国際エスケープ文字 + の詳細については、『 Cisco Unified Communications Manager システム ガイド 』の 「ルート プランの概要」 にあるの項を参照してください。

また、「関連項目」も参照してください。

インタラクション

次の各項では、ローカル ルート グループが Cisco Unified Communications Manager の他の機能およびアプリケーションとどのように通信するかについて説明します。

• 「サポートされるデバイス」

• 「自動転送」

• 「その他の補足サービス」

• 「ルート プラン レポート」

• 「Cisco Unified Mobility」

追加情報

「関連項目」を参照してください。

サポートされるデバイス

コールを発信することが可能な Cisco Unified Communications Manager のデバイス タイプはすべて、ローカル ルート グループ機能をサポートします。これには次のデバイスが含まれます。

• Skinny デバイス

• H.323 デバイス

• SIP デバイス

• MGCP デバイス（すべての PRI バリアント、BRI、および MGCP 電話機を含む）

• CTI デバイス

自動転送

自動転送されたコールに関しては、Cisco Unified Communications Manager は、プロビジョニングされているローカル ルート グループを検索するために、転送先に関連付けられたデバイス プールの設定においてプロビジョニングされているローカル ルート グループを使用します。したがって、電話機 A が（ローカルの）電話機 B にコールし、電話機 B がそのコールを（リモートの）電話機 C に転送する場合、電話機 B ではなく、電話機 A のデバイス プールのローカル ルート グループ値が使用されます。

その他の補足サービス

多くの補足サービスは、コールを発信できます。このように発信されたコールでは、ローカル ルート グループはスキップされます。

コールを発信できるのは、次の機能です。

• 折返し

• MWI

• モビリティ（フォローミー）

• パス置換

標準ローカル ルート グループがスキップされることによって検索が終了すると（つまり、標準ローカル ルート グループがルート リスト内の最後または唯一のルート グループとなった場合）、ルーティングは中断します。

コールを転送できるのは、次の機能です。

• 割り込み

• 折返し

• コール パーク

• 会議

• ダイレクト コール パーク

• 自動転送

• 即時転送

• ミートミー会議

• コール ピックアップ

「自動転送」で説明したとおり、Cisco Unified Communications Manager は、プロビジョニングされているローカル ルート グループを検索するために、転送先に関連付けられたデバイス プールの設定においてプロビジョニングされているローカル ルート グループを使用します。

ルート プラン レポート

ルート プラン レポートには、ルート リスト、関連するルート グループ、およびトランクやゲートウェイなどのルートに関する詳細が示されます。特別な標準ローカル ルート グループも示されます。次はその一例です。

ローカル ルート グループを使用しないルート パターンに対するルート プラン レポートの表示例

BoulderRouteList

|__ BoulderRG

__BoulderGW1

|__BoulderGW2

ローカル ルート グループを使用するルート プラン レポートの表示例

SystemRouteList

|__ 標準ローカル ルート グループ

Cisco Unified Mobility

リモート接続先に対するシングル ナンバー リーチ コールでは、発信側のデバイス プールによって標準ローカル ルート グループの選択が決まります。

制限事項

ローカル ルート グループを設定する前に、次の制限事項を確認してください。

• 「混合されたルート リスト」

混合されたルート リスト

SIP ルート グループ、および Q.SIG ルート グループを、同時に 1 つのルート リストに挿入することはできません。ローカル ルート グループ機能を使用する場合、混合されたルート リストの規則はプロビジョニング中には実施されません。これは、コールの設定中に、標準ローカル ルート グループと、プロビジョニングされたルート グループとの間にバインドが動的に発生するためです。このため、一部の Q.SIG 関連機能が利用できなくなる場合があります。標準ローカル ルート グループから Q.SIG ルート グループへのバインドは避けてください。

追加情報

「関連項目」を参照してください。

ローカル ルート グループのサービス パラメータの設定

ローカル ルート グループ機能は、追加のサービス パラメータの設定を必要としません。

追加情報

「関連項目」を参照してください。