Cisco Unified Communications Manager Release 10.0(1) 機能およびサービス ガイド
Multilevel Precedence and Preemption
Multilevel Precedence and Preemption

目次

Multilevel Precedence and Preemption

この章では、適切に検証されたユーザが優先コールをかけられるようにするための、Multilevel Precedence and Preemption(MLPP)サービスについて説明します。 ユーザは必要に応じて、優先順位の低いコールを差し替えることができます。

優先順位は、コールに関連付けられた優先レベルを意味します。 プリエンプションは、優先順位の高いコールがデバイスを使用できるように、現在ターゲット デバイスを使用している優先順位の低いコールを終了させるプロセスを意味します。

認証されたユーザは、宛先ステーションへ、または完全にサブスクライブされた時分割多重(TDM)トランクを介して、コールをプリエンプション処理することができます。 この機能により、国家の非常事態やネットワークの機能低下など、ネットワークに負荷がかかっている場合に、優先順位の高いユーザが重要な組織や担当者への通信を確実に行うことができます。

MLPP の設定

Multilevel Precedence and Preemption(MLPP)サービスを使用すると、適切に検証されたユーザが優先コールをかけることができます。 ユーザは必要に応じて、優先順位の低いコールを差し替えることができます。

優先順位は、コールに関連付けられた優先レベルを意味します。 プリエンプションは、優先順位の高いコールがデバイスを使用できるように、現在ターゲット デバイスを使用している優先順位の低いコールを終了させるプロセスを意味します。

認証されたユーザは、宛先ステーションへ、または完全にサブスクライブされた時分割多重(TDM)トランクを介して、コールをプリエンプション処理することができます。 この機能により、国家の非常事態やネットワークの機能低下など、ネットワークに負荷がかかっている場合に、優先順位の高いユーザが重要な組織や担当者への通信を確実に行うことができます。

次の手順を実行して、MLPP を設定します。

手順
    ステップ 1   MLPP ドメイン、リソース プライオリティ ネームスペース ネットワーク ドメイン、およびリソース プライオリティ ネームスペース ネットワーク ドメイン リストを設定します。
    ステップ 2   関連するデバイスが MLPP コールを発信できる共通デバイス設定を設定します。
    ステップ 3   エンタープライズ パラメータを設定して、MLPP 通知とプリエンプションを有効にします。 個々のデバイスおよび共通デバイス設定内のデバイスで MLPP が [デフォルト(Default)] に設定されている場合、これらのデバイスおよび共通デバイス設定には MLLP 関連のエンタープライズ パラメータが適用されます。
    ステップ 4   ユーザ(発信側および関連するデバイス)が MLPP を使用して優先コールをかけられるように、パーティションとコーリング サーチ スペース(CSS)を設定します。

    Assured Services 電話機には適用されません。

    ステップ 5   MLPP コールの MLPP 優先レベルとルート オプションを指定するルート パターン/ハント パイロットを設定します。

    Assured Services 電話機には適用されません。

    ステップ 6   MLPP コールの MLPP 優先レベルとルート オプションを指定するトランスレーション パターンを設定します。

    Assured Services 電話機には適用されません。

    ステップ 7   MLPP コールの MLPP ドメインを指定するゲートウェイを設定します。 次のゲートウェイ タイプが適用されます。
    • Cisco Catalyst 6000 24 ポート FXS ゲートウェイ
    • Cisco Catalyst 6000 E1 VoIP Gateway
    • Cisco Catalyst 6000 T1 VoIP Gateway
    • Cisco DE-30+ ゲートウェイ
    • Cisco DT-24+ ゲートウェイ
    • H.323 ゲートウェイ
    (注)     

    いくつかのゲートウェイ タイプで、[MLPP通知(MLPP Indication)] と [MLPPプリエンプション(MLPP Preemption)] を設定できます。

    ステップ 8   MLPP コールの MLPP ドメインを指定する Cisco Unified IP Phone を設定します。
    (注)     

    いくつかの電話機タイプで、[MLPP通知(MLPP Indication)] と [MLPPプリエンプション(MLPP Preemption)] を設定できます。

    ステップ 9   MLPP コールをかける電話番号を設定します。
    ステップ 10   MLPP コールをかけるユーザのユーザ デバイス プロファイルを設定します。
    ステップ 11   MLPP コールをかけるデバイスのデバイス プロファイル デフォルトを設定します。
    ステップ 12   MLPP サービスが使用可能であることをユーザに通知します。

    MLPP 機能

    Multilevel Precedence and Preemption(MLPP)サービスを使用すると、優先コールをかけることができます。 適切に検証されたユーザは、優先順位の低いコールよりも優先順位の高いコールを優先させることができます。 認証されたユーザは、宛先ステーションへ、または完全にサブスクライブされた TDM トランクを介して、コールをプリエンプション処理することができます。 この機能により、国家の非常事態やネットワークの機能低下など、ネットワークに負荷がかかっている場合に、優先順位の高いユーザが重要な組織や担当者への通信を確実に行うことができます。


    (注)  


    Multilevel Precedence and Preemption(MLPP)機能をサポートしているのは SCCP 電話機のみです。 SIP 電話機は MLPP をサポートしていません。


    MLPP の設定および操作は、Assured Services SIP(AS-SIP)エンドポイントと他の MLPP エンドポイント デバイスで少し異なります。 AS-SIP エンドポイントは、リソース プライオリティ ヘッダーを介して Unified CM に優先レベルを通知します。 他の MLPP エンドポイントはダイヤルされた番号パターンを使用して優先レベルを示します。 この章に示す例の多くは、ダイヤルされた番号を使用して優先順位を通知する MLPP の使用について説明しています。 これらのエンドポイントの操作および設定の違いについて理解するには、「Assured Services SIP エンドポイント」の項を参照してください。

    MLPP の用語

    MLPP サービスでは次の用語を使用します。

    • コール:2 人以上のユーザ間または 2 つ以上のネットワーク エンティティ間の音声、ビデオ、またはデータの接続。これは、番号をダイヤルするか、または定義済みのダイヤル プランに従って宛先にルーティングすることで実現されます。

    • 優先順位:コールに関連付けられた優先レベルを示します。

    • プリエンプション:優先順位の低い既存のコールを終了させ、優先順位の高いコールにターゲット デバイスを使用させるプロセス。

    • 優先コール:最も低い優先レベルよりも高い優先レベルを持つコール。

    • MLPP コール:優先レベルが確立された、設定中(つまり、アラート前)のコールまたは設定済みのコール。

    • アクティブなコール:接続が確立され、発信側と着信側がアクティブになったコール。

    • MLPP ドメイン ID:MLPP サブスクライバに関連付けられているデバイスとリソースの集合を指定したもの。 特定のドメインに属す MLPP サブスクライバが、同じドメインに属す別の MLPP サブスクライバに優先コールをかけると、MLPP サービスは、着信側の MLPP サブスクライバの既存のコールを優先順位の高いコールに差し替えます。 MLPP サービスは、異なるドメイン間では使用できません。

    • リソース プライオリティ ネームスペース ネットワーク ドメイン:優先コールの際の SIP トランクの動作を指定するもので、既存コールを差し替えることができます。SIP シグナリングにおけるリソース プライオリティ ネームスペース ネットワーク ドメインは、レガシー TDM MLPP ネットワークで使用されている ISDN 優先の情報要素(IE)、および ISDN ユーザ部(ISUP)の優先パラメータに似ています。 リソース プライオリティ ネームスペース ネットワーク ドメインは発信コールに含まれており、コールを SIP トランクに転送するためのトランスレーション パターンまたはルート パターンに基づいています。 着信コールに関しては、ネットワーク ドメインがリソース プライオリティ ネームスペース ネットワーク ドメイン リストに対して検証されます。 このリストにネットワーク ドメインが存在しない場合、コールは拒否され、417 メッセージ(認識不能)が返されます。

    • リソース プライオリティ ネームスペース ネットワーク ドメイン リスト:設定済みのリソース プライオリティ ネームスペース ネットワーク ドメインのリストで、着信コールの検証に使用します。

    • MLPP 通知対応のデバイス:Cisco Unified Communications Manager で、デバイスと Cisco Unified Communications Manager によってデバイス制御プロトコルで優先順位とプリエンプションのシグナリング手順がサポートされ、Cisco Unified Communications Manager システムでそのように設定されているデバイス。

    • MLPP プリエンプション対応のデバイス:Cisco Unified Communications Manager で、デバイスと Cisco Unified Communications Manager によってデバイス制御プロトコルでプリエンプションのシグナリング手順がサポートされ、Cisco Unified Communications Manager システムでそのように設定されているデバイス。 Cisco Unified Communications Manager は、このインターフェイスでプリエンプションを開始できます。

    優先順位

    優先順位は、コールに関連付けられた優先レベルを示します。 優先順位の割り当てはその場限りのものであり、ユーザは自分がかけようとしているコールに優先レベルを適用するかしないかを選択します。 MLPP の優先順位は、コール アドミッション制御または拡張型緊急通報システム(E911)とは関係していません。 ユーザは、Cisco Unified Communications Manager の管理ページの専用ダイヤル パターンによって MLPP 要求を開始できます。 発呼側(デバイスや回線など)に関連付けられたコーリング サーチ スペース(CSS)の設定によって、発呼側が優先順位パターンをダイヤルして優先コールを発信できるかどうかが制御されます。

    Defense Switched Network(DSN)および Defense Red Switched Network(DRSN)は、初期 MLPP 配置用のターゲット システムを示します。 通常は、優先レベルをコールに割り当てるメカニズムを適用しますが、Cisco Unified Communications Manager の管理ページでは、優先ダイヤル パターンやそのパターンへのアクセスを許可または制限するコーリング サーチ スペースを定義することによって、任意のダイヤル プランに優先レベルを割り当てることができます。 DSN では、ストリング プレフィックス NP を使用して優先コールを要求できるようにダイヤル プランが定義されます。NP の P は優先レベルの要求を示し、N は事前設定された MLPP へのアクセス番号を示します。 優先順位は次のとおりです。

    • エクゼクティブ オーバーライド

    • フラッシュ オーバーライド

    • フラッシュ

    • 即時

    • プライオリティ

    • ルーチン

    優先順位を呼び出さなければ、システムは通常のコール処理と自動転送を使用してコールを処理します。

    デフォルトの割り当てまたはエクステンション モビリティでユーザ プロファイルが電話機に割り当てられている場合、電話機は、ユーザに関連付けられた CSS を含め、割り当てられたユーザの設定を継承します。 ただし、電話機の CSS はユーザ プロファイルを上書きできます。 Cisco Unified Communications Manager は、パターンが一致した場合に、ダイヤルされたパターンに関連する優先レベルをコールに割り当てます。 システムは、割り当てられた優先レベルで、コール要求を優先コールとして設定します。

    ある宛先に対して優先コールが発信されると、Cisco Unified Communications Manager は、優先コールの発信元または宛先のいずれかが MLPP 通知対応である場合に、発信元と宛先の両方に優先順位のインジケータを送信します。 発信元の場合、このインジケータは、優先順位呼び戻し音と、デバイスで表示がサポートされている場合はコールの優先レベルまたはドメインの表示で示されます。 宛先の場合、このインジケータは、優先順位呼び出し音と、デバイスで表示がサポートされている場合はコールの優先レベルまたはドメインの表示で示されます。

    エクゼクティブ オーバーライド優先レベル

    最高の優先レベルとしてエクゼクティブ オーバーライド優先レベルが指定されています。 エクゼクティブ オーバーライド優先レベルが優先順位の低いコールを差し替えるときに、エクゼクティブ オーバーライド コールはその優先レベルをフラッシュ オーバーライド(次に高いレベル)に変更するため、後続のエクゼクティブ オーバーライド コールは最初の優先コールを差し替えることができます。

    エクゼクティブ オーバーライド優先コールの差し替えには、Executive Override Call Preemptable サービス パラメータを [True] に設定する必要があります。 このサービス パラメータを [False] に設定すると、エクゼクティブ オーバーライド優先コールはその優先レベルを保持するため、差し替えることができません。

    以下の図に、2 つのエクゼクティブ オーバーライド優先コールの例を示します。一方は差し替えが可能で、もう一方は差し替えができません。

    図 1. エクゼクティブ オーバーライド優先コールの例

    この例では、Cisco Unified Communications Manager インストール 1 の Executive Override Call Preemptable サービス パラメータには [False] が指定されていますが、Cisco Unified Communications Manager インストール 2 では、Executive Override Call Preemptable サービス パラメータに [True] が指定されています。

    ONA は T1 PRI 4ESS トランクを通して、インストール 1 からインストール 2 の DNA へのエクゼクティブ オーバーライド優先コールを開始します。 DNA が応答し、コールが接続されます。

    インストール 1 で、ONB がエクゼクティブ オーバーライド優先コールを使用して ONA にコールしようとすると、インストール 1 ではエクゼクティブ オーバーライド コールを差し替えることができないため、ONB はブロックされた優先権アナウンス(BPA)を受信します。 ONB がエクゼクティブ オーバーライド優先コールを使用して DNA にコールしようとすると、インストール 2 ではエクゼクティブ オーバーライド コールを差し替えることができるため、ONA と DNA の間のコールは差し替えられます。 同様に、エクゼクティブ オーバーライド優先コールを使用して DNB が DNA をコールすると、後続のエクゼクティブ オーバーライド優先コールは ONA と DNA の間のコールを差し替えます。

    エクゼクティブ オーバーライド優先コールの設定

    以下の図に、エクゼクティブ オーバーライド優先コールが行われた場合のイベントの例を示します。

    図 2. エクゼクティブ オーバーライド優先コールの設定

    この例では、電話機 1000 がオフフックになり、9*1001 をダイヤルします (ルート パターン 9*XXXX 設定にはエクゼクティブ オーバーライドが指定されています)。

    発信元では、この優先コールが成功すると、Cisco Unified Communications Manager はユーザへの呼び戻し音を再生する信号を Cisco Unified IP Phone に送ります。 Cisco Unified IP Phone 1000 が MLPP 通知対応の場合、優先の呼び戻し音が再生されます。 これ以外の場合は、通常の呼び戻し音が再生されます。

    優先コールが接続できない場合、Cisco Unified IP Phone 1000 が MLPP 通知対応であれば、ブロックされた優先権アナウンス(BPA)が再生されます。 これ以外の場合は、通常のリオーダー音が再生されます。

    宛先では、エクゼクティブオーバーライド優先コールが Cisco Unified IP Phone 1001 に正しく提供されると、デバイスで可聴呼び出し音を生成する信号が Cisco Unified Communications Manager によって宛先に送信されます。 Cisco Unified IP Phone 1001 が MLPP 通知対応の場合、優先の呼び戻し音が再生されます。 これ以外の場合は、通常の呼び出し音が再生されます。

    また、電話機 1001 が MLPP 通知対応である場合は、Cisco Unified IP Phone 1001 に優先情報(フラッシュ オーバーライド優先コール アイコンなど)が表示されます。 これ以外の場合は、優先情報は表示されません。

    PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コール

    以下の図に、PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コールの例を示します。

    図 3. PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コール

    Cisco Unified Communications Manager では、PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コールを処理する際、PRI 4ESS UUIE を介した優先レベル以外は、他の優先コールの処理に使用する方法と同じ方法を使用します。

    User-to-User を介した優先情報が渡されるのは、[サービスパラメータ設定(Service Parameter Configuration)] ウィンドウ上の [User-to-User IE Status] が [True] になっており、[ゲートウェイの設定(Gateway Configuration)] ウィンドウの [UUIEを介した優先レベルの通知(Passing Precedence Level Through UUIE)] が選択されている場合に限られます。

    DRSN への PRI 4ES UUIE ベースの MLPP インターフェイス

    Cisco Unified Communications Manager は、PRI 4ESS UUIE フィールド経由で MLPP 情報を渡すことができるようになりました。 以前のリリースの Cisco Unified Communications Manager は、Defense Switched Network(DSN)スイッチに接続するために、ANSI T1.619a 仕様に従って開発された PRI インターフェイス用の MLPP を提供しました。 Defense Red Switch Network(DRSN)スイッチは、ANSI T1.619a ベースの MLPP をサポートしていませんが、UUIE を使用することで PRI 4ESS インターフェイス上の MLPP をサポートしています。

    プリエンプション

    プリエンプション プロセスは、優先順位の高いコールがデバイスを使用できるように、現在ターゲット デバイスを使用している優先順位の低いコールを終了させます。 プリエンプションには、プリエンプション処理されるユーザへの通知とそれに対する受信応答、およびプリエンプションの直後とコールの終了前の共有リソースの予約が含まれます。 プリエンプションは、どのメソッドが起動するかに応じて、次のいずれかの形式をとります。

    • ユーザ アクセス チャネル プリエンプション:このタイプのプリエンプションは、電話機およびその他のエンドユーザ デバイスに適用されます。 また、着信側のユーザ アクセス チャネルを差し替える必要がある場合に、着信側と接続先の両方がプリエンプション通知を受信し、既存の MLPP コールがすぐにクリアされます。 着信側は、優先順位の高いコールが実行される前に、プリエンプションに受信応答する必要があります。 その後、着信側には新規 MLPP コールが提供されます。 着信側がプリエンプションに受信応答しない場合、優先順位の高いコールは 30 秒後に実行されます。

    • 共通ネットワーク ファシリティ プリエンプション:このタイプのプリエンプションはトランクに適用されます。 このタイプのプリエンプションは、ネットワーク リソースがコールで混雑しており、このうちの一部のコールの優先順位が、発呼側が要求しているコールよりも低くなっていることを意味します。 1 つまたは複数の優先順位の低いコールが、優先順位の高いコールに差し替えられます。


    (注)  


    既存のコールを差し替えるためにコールが使用するすべてのデバイスでプリエンプションが有効になっていることを確認してください。 発信側と着信側のデバイス(電話機)でプリエンプションが有効になっているだけでは不十分なので、コールに使用されるゲートウェイでもプリエンプションが有効になっていることを確認してください。


    ドメイン

    MLPP ドメインは、MLPP サブスクライバに関連付けられたデバイスとリソースの集合を指定したものです。 特定のドメインに属す MLPP サブスクライバが、同じドメインに属す別の MLPP サブスクライバに優先コールをかけると、MLPP サービスは、着信側の MLPP サブスクライバの既存のコールを優先順位の高いコールに差し替えます。 MLPP サービスは、異なるドメイン間では使用できません。

    発信ユーザによる MLPP ドメインへの加入によって、コールのドメインとその接続が決まります。 あるドメイン内の優先順位の高いコールだけが、同じドメイン内のコールが使用している接続を差し替えることができます。

    管理者は Cisco Unified Communications Manager の管理ページに、ゼロ以上の 16進数でドメインを入力します。

    リソース プライオリティ ネームスペース ネットワーク ドメイン

    リソース プライオリティ ネームスペース ネットワーク ドメインにより、SIP トランクを使用する Voice over Secured IP(VoSIP)ネットワーク向けのネームスペース ドメインを設定できるようになります。 Cisco Unified Communications Manager が SIP シグナル化されたリソースに優先順位を付けることによって、電話回線、IP 帯域幅、およびゲートウェイに緊急事態や輻輳が発生した場合にこれらのリソースが最も効率的に利用されます。 エンドポイントは、優先順位やプリエンプションに関する情報を受信します。 これは、RFC 4411 および RFC 4412 に基づいて行われます。

    SIP シグナリングは、リソース プライオリティ ヘッダーを含みます。 リソース プライオリティ ヘッダーは、レガシー TDM MLPP ネットワークで使用されている ISDN 優先の情報要素(IE)、および ISDN ユーザ部(ISUP)の優先パラメータに似ています。 リソース プライオリティ ヘッダーは、RFC 3261 (Section 20.26) のプライオリティ ヘッダーと関連していますが、同一ではありません。

    RFC 3261 プライオリティ ヘッダーは、エンドポイントに対する SIP 要求の重要度を示します。 たとえば、このヘッダーには、モバイル デバイスおよびアシスタントへのコール ルーティング、およびコールの接続先がビジーである場合のコール受理に関する決定事項が表示されます。 RFC 3261 プライオリティ ヘッダーは、PSTN ゲートウェイまたはプロキシのリソースの使用には影響を及ぼしません。

    RFC 3261 プライオリティ ヘッダーでは任意の値がアサートされますが、ネームスペース ネットワーク ドメインの Resource Priority ヘッダー フィールドは認証の対象になります。 Resource Priority ヘッダー フィールドは、IP ルータの転送動作、またはパケット転送プライオリティなどの通信リソースの使用に対して、直接的な影響を与えません。

    発信メッセージにおける RFC 4411 および RFC 4412 リソース プライオリティ ヘッダーは、コールを SIP トランクに転送するトランスレーション パターンまたはルート パターンに基づいています。 Cisco Unified Communications Manager の管理ページで設定されたエンドポイントでコールが終端している場合は、着信コールがリソース プライオリティ ネームスペース ネットワーク ドメインのリストで検証されます。

    次のメッセージには、Resource Priority ヘッダーが含まれています。

    • INVITE

    • UPDATE

    • REFER

    以下は、最優先事項(値は 4)を示すリソース プライオリティ ヘッダーを含む INVITE メッセージの例です。

    INVITE sip:6000@10.18.154.36:5060 SIP/2.0Via: SIP/2.0/TCP 10.18.154.44;branch=z9hG4bK1636ee4aRemote-Party-ID: “Raleigh - 5001" <sip:5001@10.18.154.44>;party=calling;screen=yes;privacy=offFrom: “Raleigh - 5001" <sip:5001@10.18.154.44>;tag=936ad6ec-4d3c-4a42-a812-99ac56d972e1-14875646To: <sip:6000@10.18.154.36>Date: Mon, 21 Mar 2005 14:39:21 GMTCall-ID: 1d13800-23e1dc99-4c-2c9a12ac@172.18.154.44Supported: 100rel,timer,replacesRequire: resource-priorityMin-SE:  1800User-Agent: Cisco-CCM5.0Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFYCSeq: 101 INVITEContact: <sip:5001@10.18.154.44:5060;transport=tcp>Expires: 180Allow-Events: presence, dialog, kpmlCall-Info:<sip:10.18.154.44:5060>;method=”NOTIFY;Event=telephone-event;Duration=500”Resource-Priority: namespace.4
    Max-Forwards: 70Content-Type: application/sdpContent-Length: 269v=0o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.18.154.44s=SIP Callc=IN IP4 10.18.154.45t=0 0m=audio 19580 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=ptime:20a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15
    

    また、デフォルトのリソース プライオリティ ネームスペース ネットワーク ドメインを SIP プロファイルに追加して、誤って設定された着信のネームスペース ネットワーク ドメインを処理する際に使用することもできます。


    (注)  


    トランスレーション パターンとルート パターンの番号分析がサポートされています。


    次の補足サービスがサポートされています。

    • プレシデンス コール待機

    • コール転送

    • 自動転送

    • 三者通話

    次のヘッダー、マッピング、およびキューイングはサポートされていません。

    • Accept-Resource-Priority ヘッダー

    • PRACK および ACK への RP ヘッダーの挿入

    • ネームスペースの間での優先順位のマッピング

    • コール キューイング、およびその他の MLPP 以外のサービス

    リソース プライオリティ ネームスペース ネットワーク ドメイン リスト

    リソース プライオリティ ネームスペース ネットワーク ドメイン リストは、許容可能なネットワーク ドメインを含んでおり、SIP プロファイルに追加されます。 許容可能なネットワーク ドメインがこのリストに含まれている場合、着信コールはこのリストと比較された上で処理されます。 着信コールが有効でない場合は、コールは拒否され、417 エラー応答(不明)が発呼側に送信されます。

    ロケーション ベースの MLPP

    Cisco Unified Communications Manager は、Skinny Client Control Protocol の電話機と TDM(PRI/CAS)トランクでの MLPP をサポートしています。 Cisco Unified Communications Manager は、ワイドエリア ネットワーク(WAN)リンク上の MLPP もサポートしています。 ロケーションベースのコール アドミッション制御(CAC)は、Cisco Unified Communications Manager の WAN リンクの帯域幅を管理します。 優先順位の高いコールを接続する必要がある場合、拡張されたロケーションでは、コールの優先レベル、および低い優先レベルのコールの差し替えが考慮されます。

    ロケーションの拡張とは、優先コールが着信し、そのコールを宛先のロケーションに接続する十分な帯域幅が見つからない場合に、Cisco Unified Communications Manager が優先レベルの最も低い 1 つ以上のコールを探して、コールを差し替え、優先順位の高いコールに利用できる帯域幅を確保することです。 差し替え処理を行っても帯域幅の要件を満たすことができないと、新しいコールは失敗します。

    優先順位ベースの MLPP プリエンプション

    8.6 よりも前のリリースでは、Cisco Unified Communications Manager は、新しい要求より優先順位が低いレベルのコールをランダムに選択してプリエンプション処理をしていました。 優先レベルがルーチンおよびプライオリティの 2 つの既存のコールがあり、このロケーションにフラッシュ コールが着信した場合、Cisco Unified Communications Manager は、ルーチン コールまたはプライオリティ コールをプリエンプション処理する可能性があります。 リリース 8.6 以降では、Cisco Unified Communications Manager は、常に、プライオリティ コールよりも前にルーチン コールをプリエンプション処理します。

    プリエンプション非対応番号の設定

    リリース 10.0 以降では、特定のダイヤル番号をプリエンプション非対応として指定できます。

    プリエンプション非対応番号を設定するには、[MLPPプリエンプション(MLPP Preemption)] の [無効(Disabled)] チェックボックスをオンにしてトランスフォーメーション パターンを作成し、これらをパーティションに配置します。次に、このようなパーティションのすべてを CSS (たとえば、NonPreemptionCSS)にインポートして、Non-Preemption Pattern CSS サービスパラメータでその CSS を選択します([システム(System)] > [サービスパラメータ(Service Parameters)])。


    (注)  


    ロケーション ベースの MLPP を機能させるには、MLPP Exception Level サービス パラメータを選択する必要があります。


    プリエンプション非対応番号機能の制限は、次のとおりです。

    • クラスタ間のシナリオでプリエンプション非対応機能を想定したとおりに機能させるには、すべてのクラスタにプリエンプション非対応番号を設定する必要があります。 プリエンプション非対応ステータスは、異なるクラスタの CallManager 間で信号は送信されません。

    • 着信コールが MGCP T1 CAS トランク経由で到達するシナリオでは、発呼側番号は Cisco Unified Communications Manager では使用できません。 したがって、発呼側番号のプリエンプション非対応性を確認することはできません。

    • MGCP FXO シナリオでは、コール ルーティング処理が開始した後に、発呼側番号情報がCisco Unified Communications Manager に提供されます。 したがって、発呼側番号のプリエンプション非対応性を確認することはできません。

    • オーバーラップ送信シナリオでは、ゲートウェイ選択が行われる前に、一部の数字だけが収集されます。 ダイヤルされた残りのすべての数字は、処理用にゲートウェイ経由で送信されます。 そのため、Cisco Unified Communications Manager では、ダイヤルされた完全な番号を把握できず、着信側番号のプリエンプション非対応ステータスを確認することはできません。

    CAC コール状態ベースの MLPP プリエンプション

    同じロケーションに 2 つのコールがあり、優先順位が同じで、使用するメディア タイプ(オーディオまたはビデオ)も同じ場合、Cisco Unified Communications Manager は、すでに完了したコールを選択する前に、設定段階にあるコールをプリエンプション処理します。

    ロケーション CAC は帯域幅をカウントするので、メディアが確立されたときに、帯域幅が使用されます。そのため、Cisco Unified Communications Manager は、コール設定が完了したと見なします。

    プリエンプション処理するコール数の最小化

    優先レベルとコール状態が同じで、使用するメディア タイプ(オーディオまたはビデオ)が同じコールでは、Cisco Unified Communications Manager は、プリエンプション処理するコールの数を最小限に抑えようとします。つまり、Cisco Unified Communications Manager は、少ない帯域幅のコールを複数選択するのではなく、大きい帯域幅のコールを 1 つ選択します。


    (注)  


    優先レベルの高いコールが選択される場合、Cisco Unified Communications Manager は、常に、低い優先レベルのコールをプリエンプション処理します。 このルールは、優先レベルの高いコールが必要な帯域幅を満たす場合でも適用されます。


    各コールは、異なるロケーションの 2 つのデバイスに接続するため、各ロケーションで、コールがプリエンプション処理されます。 たとえば、あるロケーションで、フラッシュ コールがプリエンプション処理され、他のロケーションでは、プライオリティ コールがプリエンプション処理されない場合もあります。 プリエンプション コールの例については、ロケーションベースのプリエンプションを参照してください。

    帯域幅の割り当てまたは調整時のビデオ コールのプリエンプション処理

    Cisco Unified Communications Manager 8.6(1) 以降では、新しい要求に対する帯域幅が十分にないときに、高い優先レベルのコールのビデオ帯域幅を割り当てまたは調整する場合、低い優先レベルのビデオ コールをプリエンプション処理します。 ビデオ コールをプリエンプション処理する場合、Cisco Unified Communications Manager は、コールをクリアして、プリエンプション処理されるパーティに対してプリエンプション トーンを再生します。

    アナンシエータまたは保留音に割り当てられる帯域幅のプリエンプション処理

    Cisco Unified Communications Manager 8.6(1) 以降では、コールのプリエンプション処理を行うときに、アナンシエータまたは保留音(MOH)に割り当てられる帯域幅をプリエンプション処理しようとします。 メディア リソース帯域幅が優先レベルの高いコールで必要な場合、アナンシエータまたは MOH が削除されるだけでなく、コール全体がクリアされます。 アナンシエータまたは MOH がコールに挿入される場合、たとえば、MLPP コールの保留音や呼び出し音を再生する、プリエンプション処理を行う、リオーダー音を再生する場合、メディアがストリーミングされます。そのため、Cisco Unified Communications Manager は、接続されるコールを考慮して、同じ優先レベルのすべての警告コールの後にコールをプリエンプション処理します。 ただし、アナンシエータまたは MOH が要求されたが、メディア ユーザ ロケーションまたはメディア リソース ロケーションのいずれでも十分な帯域幅が使用できない場合、アナンシエータまたは MOH の要求は失敗し、Cisco Unified Communications Manager は、アナンシエータまたは MOH の他のコールをプリエンプション処理しません。

    プリエンプション処理されるすべてのコールと同様、これらのコールに割り当てられる帯域幅は、すぐに解放され、別のコールに割り当てられます。 アナンシエータがプリエンプション トーン、またはコールを切断させる他のトーンで再生される場合、帯域幅がすでに解放されている場合でも、コールはしばらく再生されます。 つまり、Cisco Unified Communications Manager が、プリエンプション トーンまたはリオーダー音に使用するアナンシエータを選択する場合、帯域幅は、コールが完全にクリアされる前に、しばらくの間、オーバーサブスクライブ(オーバーバジェット)になる可能性があります。

    最大帯域幅の使用

    Cisco Unified Communications Manager 8.6(1) 以降では、ロケーションに設定されている最大帯域幅が使用されます。これにより、コールが再開または転送されるときにコールがクリアされる可能性があります。 また、新しい帯域幅要求が発生し、帯域幅がオーバーサブスクライブになると、複数のコールがクリアされることもあります。 ロケーションの最大帯域幅を使用するには、サービス パラメータ Locations-based Maximum Bandwidth Enforcement Level for MLPP Calls および Locations-based MLPP Enable を [Strict Enforcement] に設定する必要があります。

    Locations-based Maximum Bandwidth Enforcement Level for MLPP Calls サービス パラメータの値が [Lenient] から [Strict] に変更されると、コールが、割り当てられる最大帯域幅より多くなることがあります。 ただし、Cisco Unified Communications Manager は、割り当て範囲内の帯域幅を使用するためのコールのプリエンプション処理を、すぐには実行せず、同じタイプのオーディオまたはビデオ コールで新しい帯域幅が要求されたときに実行します。 プリエンプション処理が発生すると、1 つの可能性として、帯域幅使用率と最大割り当て数に大きな差が生じることがあります。

    オーバーサブスクライブ状態でのプリエンプションを処理する場合、Cisco Unified Communications Manager は、最も低い優先レベルのコールから、すべての既存のコールを考慮します。 このプリエンプションは帯域幅要求によりトリガーされますが、プリエンプション処理されるコールは、要求側コールより優先レベルが高いことがあります。

    サービス パラメータ Locations-based Maximum Bandwidth Enforcement Level for MLPP Calls は、ロケーションの帯域幅使用率を設定された最大数内に制限するかどうかを決定します。

    サービス パラメータの詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』のロケーションベースのプリエンプションを参照してください。

    帯域幅調整時のオーディオ コールのプリエンプション処理

    Cisco Unified Communications Manager は、着信側の対応、共有回線の保留と再開、転送、その他の機能のインタラクションの場合と同様に、コールが着信側に提供された後で帯域幅使用率が変わった場合、オーディオ コールの帯域幅を調整します。 Cisco Unified Communications Manager は、他のコールをプリエンプション処理しようとしますが、可能な場合、プリエンプション処理されるコールの帯域幅が十分にない場合でも、新しい帯域幅要求の処理を許可します。


    (注)  


    サービス パラメータ Enforce Maximum Bandwidth for MLPP が [True] に設定されている場合、帯域幅要求が失敗し、コールがクリアされます。 要求側コールは、原因コードおよびプリエンプション トーンが同じ他のロケーション プリエンプションとしてプリエンプション処理されるかのように、クリアされます。


    コール レッグの結合後の帯域幅の更新

    Cisco Unified Communications Manager 8.6(1) よりも前は、実際の帯域幅使用率は正確に反映されていませんでした。 たとえば、ユーザ B がユーザ A およびユーザ C を転送する場合、プライマリ コール(A および B)に予約されている帯域幅は割り当てられますが、セカンダリ コール(B および C)に予約されている帯域幅は解放されていました。

    Cisco Unified Communications Manager 8.6(1) 以降は、結合操作の直後に帯域幅が更新されます。これにより、コールの正しい帯域幅使用率が反映されます。 帯域幅が更新されると、2 つのコール レッグに割り当てられる既存の帯域幅が保持されます。 一度メディアが接続されると、Cisco Unified Communications Manager は、正しい帯域幅使用率に合わせて調整します。 つまり、帯域幅が結合操作の後に更新されると、コール レッグの一方でビデオの帯域幅が予約され、もう一方でオーディオの帯域幅が予約されることがあります。この場合、帯域幅予約のタイプが 2 つあるコールが存在することになりますが、メディア接続後、帯域幅は正しい使用率に合わせて調整されます。


    (注)  


    帯域幅の更新では、どちらのロケーションでも追加の帯域幅が必要ないので、Cisco Unified Communications Manager はコールをプリエンプション処理しません。


    コールのリダイレクト時の帯域幅の更新

    この項では、発呼側と着信側を新しい宛先にリダイレクトするときに帯域幅がどのように予約されるかについて説明します。

    発呼側の新しい宛先へのリダイレクト

    Cisco Unified Communications Manager が発呼側を新しい宛先にリダイレクトする場合、IP Phone B に予約されている帯域幅は、Cisco Unified Communications Manager がIP Phone C の帯域幅を予約しようとするときに解放されます。

    IP Phone C で予約に失敗した場合、IP Phone B の帯域幅が再び割り当てられます。 即転送障害など、A から B へのコールが復元される場合、A から B へのコールの帯域幅が正しく反映されます。

    CFNA 障害など、A から B へのコールが復元されない場合、IP Phone B の呼び出し音が停止した場合でも、IP Phone A と IP Phone B の両方の帯域幅は割り当てられたままになります。 両方の IP Phone の帯域幅は、IP Phone A がコールを切断すると解放されます。

    着呼側の新しい宛先へのリダイレクト

    着信側をリダイレクトする場合、Cisco Unified Communications Manager は、新しい宛先を呼び出す前に、元の着信側の 2 倍の帯域幅を予約します。 2 倍の帯域幅を予約できるだけの帯域幅がない場合、リダイレクト操作は失敗します。 Cisco Unified Communications Manager 8.6(1) 以降では、Cisco Unified Communications Manager は、新しい着信側の帯域幅を予約するときに、元の着信側の帯域幅予約(IP Phone B)を再使用します。 ただし、リダイレクト アクションが成功し、IP Phone A および IP Phone D が同じロケーションにある場合、Cisco Unified Communications Manager では、両方の IP Phone の帯域幅が必要になります。

    Phone D の新しい宛先の予約に失敗した場合、元の着信側に予約されている既存の帯域幅が再び割り当てられます。 元の着信側および発呼側のコールが復元されると、発呼側および元の着信側の帯域幅予約が保持されます。

    新しい宛先の予約が失敗し、元の A から B へのコールが復元されない場合、IP Phone A および IP Phone B の両方の帯域幅が解放されます。

    クラスタ間トランク経由の MLPP

    Cisco Unified Communications Manager は、クラスタ間トランク経由の MLPP 優先順位とプリエンプションをサポートしています。 ダイヤルした数値によって優先レベルを通知します。 ロケーション コール アドミッション制御メカニズムは、プリエンプションを制御します。 アナウンスと MLPP 原因コードも、クラスタ間トランク経由で使用できます。

    MLPP 優先パターン

    MLPP 優先順位パターンを設定するには、Cisco Unified Communications Manager の管理ページの [トランスレーションパターンの設定(Translation Pattern Configuration)] ウィンドウにアクセスします。このウィンドウでは、次の MLPP 優先順位パターンを使用できます。

    • エクゼクティブ オーバーライド(最高)

    • フラッシュ オーバーライド

    • フラッシュ

    • 即時

    • プライオリティ

    • 標準(最低)

    • デフォルト(優先レベルが変更されないことを意味します)

    詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

    MLPP 表示対応

    MLPP 通知対応のデバイスには次の特徴があります。

    • MLPP 通知対応のデバイスは、プリエンプション トーンを再生できます。

    • MLPP 通知対応のデバイスは、アナウンス サーバが生成する MLPP プリエンプション アナウンスを受信できます。

    • MLPP 通知対応のデバイスは、プリエンプションを受信できます。

    デバイスを設定して MLPP 通知を有効にするには、各デバイスの設定ウィンドウを使用します。 各デバイスの [MLPP通知(MLPP Indication)] フィールドで、値を [オン(On)] に設定します。

    デバイスの MLPP 通知設定の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

    優先コールの設定

    優先コールの設定では、次の一連のイベントが発生します。

    1. ユーザが電話機をオフフックにして優先コールをダイヤルします。 コール パターンは NP-XXX を指定しています。ここで、N は優先アクセス番号を示し、P はコールの優先レベルを示します。

    2. 発呼側は、コールの処理中に特別な優先順位呼び戻し音と優先順位表示を受信します。

    3. 着信側は、優先コールを示す特別な優先順位呼び出し音と優先順位表示を受信します。

    ユーザ 1000 がユーザ 1001 に優先コールをかけます。 そのために、ユーザ 1000 は 90-1001 などの優先コール パターンをダイヤルします。

    コールが処理されると、発呼側の Cisco Unified IP Phone が優先順位呼び戻し音と優先順位表示を受信します。 着信側が優先コールに受信応答すると、着信側の Cisco Unified IP Phone は、優先順位呼び出し音(特別な呼び出し音)と優先順位表示を受信します。

    クラスタ間トランクの間での優先コールの設定

    以下の図に、クラスタ間トランクの間での優先コールに使用できる設定例を示します。 クラスタ間トランクの間には、優先情報要素のサポートは存在しないため、追加ディジットを転送することで優先情報を送信します。 優先情報の送信を実行するには、両方のクラスタでダイヤル プランを適切に設定する必要があります。

    図 6. クラスタ間トランクの間での優先コールの設定例

    この例では、1000 は 92-2000 をダイヤルします。これは両方のクラスタの適切な優先順位パターンに一致しており、優先コールを設定します。

    Alternate Party Diversion

    Alternate Party Diversion(APD)は、特別なタイプの自動転送から構成されます。 ユーザが APD に設定されている場合は、通話中または応答のない電話番号(DN)に優先コールがかけられたときに APD が実行されます。

    MLPP APD は優先コールだけに適用されます。 MLPP APD コールは、優先コールの DN 無応答時転送の設定を無効にします。

    通常、優先コールは、Use Standard VM Handling For Precedence Calls エンタープライズ パラメータの値で制御されるので、ボイスメール システムには転送されません。 詳細については、MLPP のエンタープライズ パラメータの設定を参照してください。

    APD を設定するために、管理者は、MLPP 優先コールのターゲットとなる電話番号の [電話番号の設定(Directory Number Configuration)] ウィンドウで [MLPP代替パーティの設定(MLPP Alternate Party Settings)] を設定します。 詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

    以下の図に、着信側が優先コールを受信し、Alternate Party Diversion の発信先が設定されている場合の Alternate Party Diversion を示します。

    図 7. Alternate Party Diversion の例

    この例では、発呼側がユーザ 1000 に優先コールをかけます。 着信側の 1000 には話中転送(CFB)用に 2000 が設定され、Call Forward Alternate Party(CFAP)用に 1001 が設定されています。 この図には、この例の他のすべてのユーザの CFB 設定と CFAP 設定が示されています。

    1000 が優先コールを受信したときに通話中である場合、コールはユーザ 2000 に送信されます。 ユーザ 2000 も通話中である場合、コールはユーザ 3000 に送信されます。 ユーザ 2000 もユーザ 3000 もコールに応答しない場合、コールはユーザ 1001 に送信されます。 つまり、コールは、元の着信側に関連する話中転送ユーザに対して指定された代替パーティではなく、元の着信側に対して指定された代替パーティに送信されます。

    同様に、ユーザ 1001 が通話中でコールに応答しない場合、コールはユーザ 5000 に転送されます。 ユーザ 5000 が通話中である場合、コールはユーザ 6000 に転送されます。 ユーザ 5000 もユーザ 6000 もコールに応答しない場合、コールはユーザ 1001 の代替パーティであるユーザ 1002 に転送されます。 ユーザ 1002 が通話中で応答しない場合、コールはユーザ 1002 の代替パーティであるユーザ 1003 に転送されます。

    MLPP プリエンプション対応

    MLPP プリエンプションを有効にするには、プリエンプション機能のあるデバイスでプリエンプションを明示的に設定します。

    プリエンプションの受信

    プリエンプションが無効になっているデバイス([MLPPプリエンプション(MLPP Preemption)] 値が [無効(Disabled)] に設定されているデバイス)は、MLPP ネットワークで優先コールを受信できますが、そのデバイス自体をプリエンプション処理することはできません。 プリエンプションが無効になっているデバイスは(別のデバイスで)、差し替えられたコールに接続できます。この場合、デバイスはプリエンプションを受信します。

    プリエンプション対応

    デバイスでプリエンプションを有効にするには、デバイスの [MLPPプリエンプション(MLPP Preemption)] 値を [強制(Forceful)] または [デフォルト(Default)] に設定します。 デバイスの [MLPPプリエンプション(MLPP Preemption)] 値が [強制(Forceful)] に設定されている場合、システムは、その独自のインターフェイスでデバイスをプリエンプション処理することができます。 つまり、デバイスは、優先コールがデバイス リソースについて競合している場合にプリエンプション処理を受けることができます。

    デバイスの [MLPPプリエンプション(MLPP Preemption)] 設定が [デフォルト(Default)] である場合、デバイスは共通デバイス設定から [MLPPプリエンプション(MLPP Preemption)] 設定を継承します。 デバイスの共通デバイス設定の [MLPPプリエンプション(MLPP Preemption)] 設定が [強制(Forceful)] である場合や、共通デバイス設定の [MLPPプリエンプション(MLPP Preemption)] 設定が [デフォルト(Default)] で MLPP Preemption Setting エンタープライズ パラメータ値が [Forceful Preemption] である場合、デバイスは有効なプリエンプションを継承します。

    デバイスを設定して MLPP プリエンプションを有効にするには、各デバイスの設定ウィンドウを使用します。 各デバイスの [MLPPプリエンプション(MLPP Preemption)] フィールドで、値を [強制(Forceful)] または [デフォルト(Default)] に設定します。

    デバイスの MLPP プリエンプション設定の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

    プリエンプションの詳細

    次の種類のプリエンプションが存在します。

    • ユーザ アクセス プリエンプション

    • 共通ネットワーク ファシリティ プリエンプション

    • ロケーションベースのプリエンプション

    ユーザ アクセス プリエンプション

    低いレベルの優先コールがすでにアクティブであるユーザに優先コールを行う場合、ユーザアクセス プリエンプションが実行されます。 いずれのコールも同じ MLPP ドメインに存在します。 このタイプのプリエンプションは、Cisco Unified Communications Manager MLPP システムで Cisco Skinny Client Control Protocol が制御する MLPP 通知対応の電話機に対して使用できます。 プリエンプションは、優先コール要求が検証された場合や、要求されたコールの優先順位が宛先の MLPP プリエンプション対応の電話機で接続されている既存のコールの優先順位よりも高い場合に実行されます。 コール処理は、プリエンプション トーンを使用して接続先にプリエンプションを通知し、アクティブなコールをリリースします。 着信側は電話を切ることによってプリエンプションに応答し、新規 MLPP コールを取得します。

    ユーザ アクセス プリエンプションで実行される一連のステップを理解するために、次の例を参照してください。

    以下の図は、ユーザ アクセス プリエンプションの例を示しています。

    図 8. ユーザ アクセス プリエンプションの例

    このユーザ アクセス プリエンプションの例では、次の一連のイベントが発生します。

    1. ユーザ 1000 がユーザ 1001 に優先レベルがフラッシュ オーバーライドの優先コールをかけ、ユーザ 1001 がそれに応答します。 この例では、ユーザ 1000 が優先コールをかけるために 90-1001 をダイヤルします。

    2. ユーザ 1002 が 9*-1001 をダイヤルしてユーザ 1001 に優先コールをかけます。 このコールの優先レベルはエクゼクティブ オーバーライドであるため、アクティブな優先コールよりも優先順位の高いコールになります。

    3. ユーザ 1001 にコールが送信されると、発呼側は優先順位表示を受信(つまり、エクゼクティブ オーバーライド表示ではなく、フラッシュ オーバーライド表示)し、既存の優先順位の低いコールのユーザはどちらもプリエンプション トーンを受信します。

    4. プリエンプションを実行するために、優先順位の低いコールのユーザ(ユーザ 1000 とユーザ 1001)が電話を切ります。

    5. 優先順位の高いコールがユーザ 1001 に送信され、ユーザ 1001 は優先順位呼び出し音を受信します。 発呼側であるユーザ 1002 は、優先順位呼び戻し音を受信します。

    このインスタンスでは別個のプリエンプションが実行されます。 優先順位の高いコールの宛先ではないユーザに対しては、再利用以外のプリエンプション処理が実行されます。 このインターフェイスではプリエンプションは実行されないので、このデバイスでプリエンプションが有効である必要はありません。 優先順位の高いコールの宛先であるユーザに対しては、再利用のプリエンプション処理が実行されます。 このインターフェイスではプリエンプションが実行されるので、このデバイスでプリエンプションが有効であることを確認してください。

    User Access Channel Nonpreemptable

    エンドユーザ デバイスは MLPP 通知対応として設定できますが、MLPP プリエンプション対応としては設定できません。 この場合、電話機は(特別なプリエンプション トーンと呼び出し音を使用して)MLPP 通知を生成できますが、Cisco Unified Communications Manager のデバイス制御プロトコルではプリエンプションがサポートされていません。 管理者は、Cisco Unified Communications Manager の管理ページがプリエンプション処理をサポートしている場合でも、電話機でプリエンプション処理を無効にすることもできます。

    以前から、ユーザ アクセス デバイス(電話機)では、複数の同時コールを処理するメカニズムが制限されているか、まったくありませんでした。 コール待機機能でも、多数の電話機および関連するスイッチには、ユーザが同じ回線で複数のコールを同時に管理できるようなメカニズムはありません。

    Cisco Unified Communications Manager の管理ページでは、コール待機機能を効果的に拡張し、Cisco Unified IP Phone 7940、7942、7945、7960、7962、7965 および 7975 のユーザにこの機能を提供しています。 これらの Cisco Unified IP Phone には、ユーザが Cisco Unified Communications Manager システムとインターフェイスする際に複数の同時コールを適切に制御するためのユーザ インターフェイスが含まれています。 この拡張機能を使用すると、ユーザがすでに他のコールを管理している場合でも、これらのタイプの電話機に送信されたすべての優先コールにコール待機機能を適用できます。 ユーザが優先コールを受信すると、宛先の電話機のユーザは、優先順位の低いコールを単にリリースするだけでなく、既存のコールをどう処理するかを決定できます。 これらのデバイスのユーザに対して、Cisco Unified Communications Manager の管理者は、Cisco Unified Communications Manager でこの機能を利用するために、デバイスを非 MLPP プリエンプション対応として設定できます。

    共通ネットワーク ファシリティ プリエンプション

    共通ネットワーク ファシリティ プリエンプションは、MLPP システムでトランクなどのネットワーク リソースに適用されます。 共通ネットワーク ファシリティでプリエンプションが行われると、既存のコールのユーザすべてがプリエンプションの通知を受信し、既存の接続がすぐに切断されます。 新規コールは、新しい着信側への特別な通知なしで、プリエンプション処理されるファシリティを使用して通常どおり設定されます。 ターゲット MGCP ゲートウェイ プラットフォーム上の PRI トランクと T1-CAS トランクは、Cisco Unified Communications Manager でこのタイプのプリエンプションをサポートします。

    プリエンプションは、優先コール要求が検証された場合や、要求されたコールの優先順位が宛先の MLPP プリエンプション対応のトランクを介した既存のコールの優先順位よりも高く、トランクが完全に使用中である(つまり、コールをそれ以上処理できない)場合に実行されます。 コール処理は、優先順位の低いコールを特定し、接続されたユーザに PRI トランク インターフェイスのプリエンプションを通知し、後続の使用のためにチャネルを予約し、選択された優先順位の低いコールを切断します。 システムは予約されたチャネルを使用して、プリエンプションを起動した優先コール用にゲートウェイを介して接続を確立します。

    共通ネットワーク ファシリティ プリエンプションで実行される一連のステップについては、次の例を参照してください。

    例 1

    以下の図は、共通ネットワーク ファシリティ プリエンプションの例を示しています。

    図 9. 共通ネットワーク ファシリティ プリエンプションの例

    この共通ネットワーク ファシリティ プリエンプションの例では、次の一連のイベントが発生します。

    1. ユーザ 1000 がユーザ 2000 に優先レベルがフラッシュ オーバーライドの優先コールをかけ、ユーザ 2000 がそれに応答します。 この例では、ユーザ 1000 が優先コールをかけるために 90-2000 をダイヤルします。 優先レベルがフラッシュ オーバーライドのフラッシュ コールはアクティブを指定します。

      コールは、2 つのゲートウェイが完全にサブスクライブされた TDM トランクを定義する共通ネットワーク ファシリティを使用します。

    2. ユーザ 1001 は次に、9*-2001 をダイヤルしてユーザ 2001 に優先順位の高い(エクゼクティブ オーバーライド)コールをかけます (フラッシュ コールがゲートウェイ A 上で最も優先順位の低いコールであることと、ユーザ 1000 とユーザ 1001 が同じ MLPP ドメイン内にあることを想定しています)。

      ゲートウェイ A でプリエンプションが実行され、ゲートウェイ A が再利用のためプリエンプション処理されます。 このインターフェイスではプリエンプションが実行されるので、このデバイスでプリエンプションが有効であることを確認する必要があります。 ゲートウェイ B も再利用のためプリエンプション処理されますが、このインターフェイスではプリエンプションは実行されないので、このデバイスでプリエンプションを有効にする必要はありません。

      ユーザ 1000 とユーザ 2000 の両方がプリエンプション トーンを受信します。 どちらのデバイスも再利用のためのプリエンプション処理はされず、これらのインターフェイスではプリエンプションは実行されないので、これらのデバイスでプリエンプションを有効にする必要はありません。

    この例では、ほとんどすべてのイベントが即時に発生します。 共通ネットワーク ファシリティ プリエンプションを実行するために、ユーザが電話を切る必要はありません。

    例 2

    以下の図に、リトライ タイマー Trr のある共通ネットワーク ファシリティ プリエンプションの例を示します。 リトライ タイマー Trr は、あるチャネルでプリエンプションが成功しなかった場合に別のチャネルでプリエンプションを再試行するメカニズムを提供します。 このタイマーは、TDM トランクだけに適用されます。

    図 10. リトライ タイマー Trr のある共通ネットワーク ファシリティ プリエンプションの例

    このリトライ タイマー Trr のある共通ネットワーク ファシリティ プリエンプションの例では、次の一連のイベントが発生します。

    1. 優先順位がフラッシュ オーバーライドの着信コールが PRI トランク デバイスに到着します。

      着信コールによってチャネル 3 のプリエンプションが起動しますが、リトライ タイマー Trr で指定された時間内に応答がありません。

    2. リトライ タイマー Trr が時間切れになります。

      チャネル 3 でプリエンプションが実行されます。

    3. このプリエンプションによって応答が行われ、チャネル 1 で優先コールが発信されます。

    ロケーションベースのプリエンプション

    次の例では、ロケーションベースのプリエンプションについて説明します。

    例 1

    次の例では、別のデバイスで新しいコールとロケーション優先コールが実行されます。 この種類のロケーションベースのプリエンプションの例については、以下の図を参照してください。

    図 11. 別のデバイスにおけるロケーションベースのプリエンプション

    この例では、ロケーションベースのプリエンプションのシナリオについて説明します。 この例には、3 種類のロケーションが存在します。

    • リモート ロケーション 0(RL0)には電話機 A があり、160K の帯域幅が使用可能

    • リモート ロケーション 1(RL1)には電話機 B と電話機 C があり、80K の帯域幅が使用可能

    • リモート ロケーション 2(RL2)には電話機 D があり、240K の帯域幅が使用可能

    次の一連のイベントが順に発生します。

    1. A はプライオリティ優先レベルで B へのコールを行い、このコールがアクティブになります。 使用可能な帯域幅として、RL0 では 80K、RL1 では 0K、RL2 では 240K が指定されています。

    2. D は、即時優先レベルで C にコールします。 RL1 の帯域幅が足りず、D のコールの優先順位が高いため、D のコールは A と B の間のコールを差し替えます。

    3. D と C の間のコールが実行されます。 使用可能な帯域幅として、RL0 では 160K、RL1 では 0K、RL2 では 160K が指定されています。

    例 2

    次の例では、同一のデバイスで新しいコールとロケーション優先コールが実行されます。 この種類のロケーションベースのプリエンプションの例については、以下の図を参照してください。

    図 12. 同一デバイスでのロケーションベースのプリエンプション

    この例では、ロケーションベースのプリエンプションのシナリオについて説明します。 この例には、3 種類のロケーションが存在します。

    • リモート ロケーション 0(RL0)には電話機 A があり、160K の帯域幅が使用可能

    • リモート ロケーション 1(RL1)には電話機 B があり、80K の帯域幅が使用可能

    • リモート ロケーション 2(RL2)には電話機 D があり、240K の帯域幅が使用可能

    次の一連のイベントが順に発生します。

    1. A はプライオリティ優先レベルで B へのコールを行い、このコールがアクティブになります。 使用可能な帯域幅として、RL0 では 80K、RL1 では 0K、RL2 では 240K が指定されています。

    2. D は、即時優先レベルで B にコールします。 RL1 の帯域幅が足りず、D のコールの優先順位が高いため、D のコールは A と B の間のコールを差し替えます。

    3. B はまずプリエンプション トーンを受信して、次に [終了] ソフトキーが表示されます。

    4. B は、[終了] ソフトキーを押し、電話を切るか、タイムアウトするまで待ちます。 D から B へのコールは B に送信されます。 D から B へのコールを実行すると、使用可能な帯域幅は、RL0 では 160K、RL1 では 0K、RL2 では 160K です。

    例 3

    次の例では、優先レベルに基づいた基本的な MLPP プリエンプションについて説明します。

    ロケーションに次のコールが存在します。

    エクゼクティブ オーバーライド:

    • コール 1、80 kbps

    • コール 2、8 kbps

    フラッシュ オーバーライド:

    • コール 3、8 kbps

    • コール 4、8 kbps

    フラッシュ:

    • コール 5、8 kbps

    • コール 6、8 kbps

    即時:

    • コール 7、8 kbps

    • コール 8、8 kbps

    プライオリティ:

    • コール 9、8 kbps

    • コール 10、8 kbps

    ルーチン:

    • コール 11、8 kbps

    • コール 12、8 kbps

    このロケーションではこれ以上の帯域幅を使用できません。

    このロケーションで 80 kbps 帯域幅を必要とする新しいエクゼクティブ オーバーライド コールが試行されます。 この場合、コール 3 ~ 12 がプリエンプション処理されます。

    例 4

    次に、Cisco Unified Communications Manager が複数の下位優先レベルのコールと 1 つの上位優先レベルのコールをプリエンプション処理する例について説明します。

    ロケーションに次のコールが存在します。

    エクゼクティブ オーバーライド:

    • NA

    フラッシュ オーバーライド:

    • NA

    フラッシュ:

    • コール 1、80 kbps

    • コール 2、8 kbps

    即時:

    • コール 3、8 kbps

    • コール 4、8 kbps

    • コール 5、8 kbps

    • コール 6、8 kbps

    • コール 7、8 kbps

    • コール 8、8 kbps

    プライオリティ:

    • コール 9、8 kbps

    • コール 10、8 kbps

    ルーチン:

    • コール 11、8 kbps

    このロケーションではこれ以上の帯域幅を使用できません。

    このロケーションで 80 kbps 帯域幅を必要とする新しいエクゼクティブ オーバーライド コールが試行されます。 この場合、Cisco Unified Communications Manager は、コール 2 で使用できる帯域幅が十分にあるため、コール 2 ~ 11 をプリエンプション処理します。コール 1 には十分な帯域幅があります。

    例 5

    次の例に、Cisco Unified Communications Manager がエクゼクティブ オーバーライドまたは下位優先レベルのコールを他のコールの前にプリエンプション処理する方法について説明します。

    ロケーションに次のコールが存在します。

    エクゼクティブ オーバーライド:

    • コール 1、80 kbps

    • コール 2、8 kbps

    フラッシュ オーバーライド:

    • コール 3、80 kbps

    • コール 4、8 kbps

    フラッシュ:

    • コール 5、8 kbps

    • コール 6、8 kbps

    即時:

    • コール 7、8 kbps

    • コール 8、8 kbps

    プライオリティ:

    • コール 9、8 kbps

    • コール 10、8 kbps

    ルーチン:

    • コール 11、8 kbps

    このロケーションではこれ以上の帯域幅を使用できません。

    このロケーションで 80 kbps 帯域幅を必要とする新しいエクゼクティブ オーバーライド コールが試行されます。 この例では、Cisco Unified Communications Manager はコールと、コール 5 ~ 11 をプリエンプション処理します。

    例 6

    次に、Cisco Unified Communications Manager が、最小の帯域幅で最大の帯域幅をプリエンプション処理する例について説明します。

    ロケーションに次のコールが存在します。

    フラッシュ:

    • コール 3、80 kbps

    • コール 4、8 kbps

    • コール 5、8 kbps

    • コール 6、8 kbps

    このロケーションではこれ以上の帯域幅を使用できません。

    このロケーションで 8 kbps 帯域幅を必要とする新しいエクゼクティブ オーバーライド コールが試行されます。 この例では、Cisco Unified Communications Manager は、コール 4、5、6 のいずれか 1 つをプリエンプション処理します。

    例 7

    次の例では、優先レベルに基づいたプリエンプションについて説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 100 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    IP Phone A および IP Phone B は、ロケーション Hub None にあり、IP Phone X および IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone A(ロケーション Hub None)が、IP Phone X(ロケーション LOC-BR1)をコールします。 コールは、ルーチン優先レベルで発信されます。 LOC-BR1 では使用できるオーディオ帯域幅が十分にあるので、コールは、IP Phone X の警告を開始し、対応されます。

    2. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、プライオリティ優先レベルで発信されます。

    3. セカンド コールを完了するために使用できる帯域幅は十分になく、セカンド コールが最初のコールより高い優先順位で発信されているので、最初のコールがプリエンプション処理されます。

    4. IP Phone B および IP Phone Y 間のコールは完了し、IP Phone A および IP Phone X 間のコールはクリアされます。

    例 8

    次の例は、プリエンプション処理されないエクゼクティブ オーバーライド コールについて説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 100 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    サービス パラメータ Executive Override Call Preemptable は [False] に設定されます。

    IP Phone A および IP Phone B は、ロケーション Hub None にあり、IP Phone X および IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone A(ロケーション Hub None)が、IP Phone X(ロケーション LOC-BR1)をコールします。 コールは、エクゼクティブ オーバーライド優先レベルで発信されます。 LOC-BR1 では使用できるオーディオ帯域幅が十分にあるので、コールは、IP Phone X の警告を開始し、対応されます。

    2. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、エクゼクティブ オーバーライド優先レベルで発信されます。

    3. セカンド コールを完了するために使用できる帯域幅が十分にないので、拒否されます。

    4. IP Phone B および IP Phone Y 間のコールは拒否されます。

    例 9

    次の例は、エクゼクティブ オーバーライド コールのプリエンプション処理について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 100 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    サービス パラメータ Executive Override Call Preemptable は [True] に設定されます。

    IP Phone A および IP Phone B は、ロケーション Hub None にあり、IP Phone X および IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone A(ロケーション Hub None)が、IP Phone X(ロケーション LOC-BR1)をコールします。 コールは、エクゼクティブ オーバーライド優先レベルで発信されます。 LOC-BR1 では使用できるオーディオ帯域幅が十分にないので、コールは、IP Phone X の警告を開始し、対応されます。

    2. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、エクゼクティブ オーバーライド優先レベルで発信されます。

    3. セカンド コールを完了するために使用できる帯域幅が十分になく、Executive Override Call Pre-emptable サービス パラメータが [True] に設定されているので、最初のコールは、プリエンプション処理されます。

    4. IP Phone B および IP Phone Y 間のコールは完了し、IP Phone A および IP Phone X 間のコールはクリアされます。

    例 10

    次に、Cisco Unified Communications Manager が帯域幅に基づいてコール プリエンプションを選択する例を示します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ オーバーライド優先レベルのコール 1。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ オーバーライド優先レベルのコール 2。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ オーバーライド優先レベルのコール 3。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、エクゼクティブ オーバーライド優先レベルで発信され、地域コーデックは、64 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分にないので、コール 3 は、プリエンプション処理されます。

    3. IP Phone B および IP Phone Y 間のコールは完了します。

    例 11

    次に、十分な帯域幅を取得できないため Cisco Unified Communications Manager がコールをプリエンプション処理しない例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ オーバーライド優先レベルのコール 1。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ優先レベルのコール 2。接続され、LOC-BR1 で 24 kbps(G.729)を使用します。

    • フラッシュ優先レベルのコール 3。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、フラッシュ オーバーライド優先レベルで発信され、地域コーデックは、64 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分になく、コールをプリエンプション処理できないので、IP Phone B および IP Phone Y 間のコールは拒否されます。

    例 12

    次に、Cisco Unified Communications Manager が、可能な限り、必要な帯域幅だけをプリエンプション処理する例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ優先レベルのコール 2。接続され、LOC-BR1 で 24 kbps(G.729)を使用します。

    • フラッシュ優先レベルのコール 3。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、フラッシュ オーバーライド優先レベルで発信され、地域コーデックは、24 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分にないので、コール 2 は、プリエンプション処理されます。

    3. IP Phone B および IP Phone Y 間のコールは完了します。

    例 13

    次に、すべてのコールがアラートを発生しているときに Cisco Unified Communications Manager が最小数のコールをプリエンプション処理する例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。アラートを発生し、LOC-BR1 で 24 kbps(G.729)を使用します。

    • フラッシュ優先レベルのコール 2。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 3。アラートを発生し、LOC-BR1 で 80 kbps(G.711)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、フラッシュ オーバーライド優先レベルで発信され、地域コーデックは、24 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分にないので、コール 1 は、プリエンプション処理されます。

    3. IP Phone B および IP Phone Y 間のコールは完了します。

    例 14

    次に、Cisco Unified Communications Manager が、同じ優先レベルで接続されているコールの前に、アラートを発生しているコールをプリエンプション処理する例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ優先レベルのコール 2。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 3。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、フラッシュ オーバーライド優先レベルで発信され、地域コーデックは、24 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分にないので、コール 2 およびコール 3 は、プリエンプション処理されます。

    3. IP Phone B および IP Phone Y 間のコールは完了します。

    例 15

    次に、Cisco Unified Communications Manager が上位優先レベルのコールの前に下位優先レベルのコールをプリエンプション処理する例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ オーバーライド優先レベルのコール 1。接続され、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ優先レベルのコール 2。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 3。接続され、アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 4。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、エクゼクティブ オーバーライド優先レベルで発信され、地域コーデックは、24 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分にないので、コール 3 およびコール 4 は、プリエンプション処理されます。

    3. IP Phone B および IP Phone Y 間のコールは完了します。

    例 16

    次の例では、元の優先順位と見なされる保留音を受信するコールについて説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。現在、保留音を受信していて(ロケーション LOC-BR1)、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ優先レベルのコール 2。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 3。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    1. IP Phone B(ロケーション Hub None)が、IP Phone Y(ロケーション LOC-BR1)をコールします。 コールは、フラッシュ優先レベルで発信され、地域コーデックは、24 kbps オーディオ ビット レートを指定します。

    2. コールを完了するために使用できる帯域幅が十分になく、コールをプリエンプション処理できないので、IP Phone B および IP Phone Y 間のコールは拒否されます。

    例 17

    次の例では、保留音を受信していて、MOH のロケーションのプリエンプションのためにプリエンプション処理されるコールについて説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 100 kbps です。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。現在、保留音を受信していて(ロケーション LOC-BR1)、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ オーバーライド優先レベルのコール 2。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    エクゼクティブ オーバーライド優先レベルの新しいコールが、別のロケーションから LOC-BR1 に試行されます。ここでは、80 kbps が要求されます。

    LOC-BR1 で使用できる帯域幅が十分にないので、コール 1 は、MOH ロケーションのプリエンプションのためにプリエンプション処理されます。 最初の MOH よりも前のコールもプリエンプション処理されます。


    (注)  


    MOH およびアナンシエータの挿入により、コールが下位優先レベルであっても、別のコールがプリエンプション処理されることはありません。


    例 18

    次に、帯域幅が不十分なために呼び出し音の挿入が失敗する例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 100 kbps です。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。現在、LOC-BR1 で 80 kbps(G.711)を使用しています。

    • フラッシュ オーバーライド優先レベルのコール 2。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    フラッシュ優先レベルの新しいコールが、LOC-BR1 から試行されます。ここでは、アナンシエータを LOC-BR1 に挿入して呼び出し音を再生する必要があります。

    使用できる帯域幅が十分にないので、要求は拒否され、アナンシエータは挿入されません。

    例 19

    次の例では、帯域幅が不十分なため、アナンシエータにより再生されるプリエンプション トーンがプリエンプション処理される例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 120 kbps です。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。現在、プリエンプション トーンのアナンシエータ(ロケーション LOC-BR1)を使用し、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ オーバーライド優先レベルのコール 2。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 3。接続され、LOC-BR1 で 16 kbps(G.728)を使用します。

    新しいコールは、LOC-BR1 から別のロケーションに試行されます。 コールは、80 kbps(G.711)を要求し、フラッシュ オーバーライド優先レベルを使用します。

    LOC-BR1 で使用できる帯域幅が不十分なため、プリエンプション コールを受信しているコール 1 が、選択され、プリエンプション処理されます(プリエンプション トーンの再生は終了します)。

    例 20

    次の例では、帯域幅が不十分なため、アナンシエータにより再生されるプリエンプション トーンがプリエンプション処理される例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 120 kbps です。

    LOC-BR1 には、次のコールが含まれます。

    • フラッシュ優先レベルのコール 1。現在、プリエンプション トーンのアナンシエータ(ロケーション LOC-BR1)を使用し、LOC-BR1 で 80 kbps(G.711)を使用します。

    • フラッシュ オーバーライド優先レベルのコール 2。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    • フラッシュ優先レベルのコール 3。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    新しいコールは、LOC-BR1 から別のロケーションに試行されます。 コールは、80 kbps(G.711)を要求し、フラッシュ オーバーライド優先レベルを使用します。

    LOC-BR1 で使用できる帯域幅が十分にないので、アラートを発生しているコール 3 は、プリエンプション処理され、プリエンプション トーンを受信しているコール 1 は、トーンの再生を継続します。

    例 21

    次の例では、発信側および受信側の両方でのプリエンプションについて説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    ロケーション(LOC-BR2)の合計オーディオ帯域幅は 140 kbps です。

    システムには次のコールが存在します。

    • 通常優先レベルのコール 1。80 kbps を使用して LOC-BR1 から LOC-BR2 に発信されます。

    • 新しいコールが、80 kbps を使用して LOC-BR1 から LOC-BR2 にフラッシュ プライオリティ優先レベルで試行されます。

    コール 1 がプリエンプション処理され、新しいコールが許可されます。

    例 22

    この例では、ビデオ コールに 384 K の帯域幅が必要です。 ロケーション A では、最大で 500 K のビデオ帯域幅および 500 K のオーディオ帯域幅を使用できます。

    SIP トランクは、ロケーション A のクラスタ 1 にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、ビデオ コールを IP Phone B に発信します。 コールが対応され、ビデオが確立されます。

    2. IP Phone C が、フラッシュ優先レベルで、SIP トランクを介してビデオ コールを IP Phone D に発信します。

    3. C から D のビデオ コールの帯域幅を予約する間、C から D のコールは、A から B のコールをプリエンプション処理します。これは、A から B のコールの優先レベルが低く、C から D のコールで 384 K の帯域幅を必要とするためクラスタ 1 のロケーション A に A から B のコールに使用できる帯域幅が十分にないためです。

    4. A から B のコールはクリアされます。

    例 23

    この例では、ビデオ コールに 384 K の帯域幅が必要です。 ロケーション A では、最大で 500 K のビデオ帯域幅および 500 K のオーディオ帯域幅を使用できます。

    SIP トランクは、ロケーション A のクラスタ 1 にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、コールを IP Phone B に発信します。

    2. IP Phone C が、フラッシュ優先レベルで、SIP トランクを介してコールを IP Phone D に発信します。

    3. オーディオのメディアが、両方のコールに対して正常に確立されます。

    4. A から B のコールが、IP Phone B によりビデオ コールにエスカレートされます。 ビデオ接続が正常に確立されます。

    5. C から D のコールが、IP Phone D によりビデオ コールにエスカレートされます。 メディアが C から D のビデオに接続され、A から B のコールがプリエンプション処理されます。これは、A から B の優先レベルが、C から D の優先レベルより低く、A から B のコールに保持できる帯域幅がロケーション A に十分にないためです。

    6. C から D のビデオ コールが、正常に確立されます。

    例 24

    この例では、新しいビデオ コールには、768 K の帯域幅が必要で、既存のビデオ コールには、384 K の帯域幅が予約されています。 ロケーション A では、最大で 400 K のビデオ帯域幅および 400 K のオーディオ帯域幅を使用できます。

    SIP トランクは、ロケーション A にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、コールを IP Phone B に発信します。

    2. IP Phone C が、フラッシュ優先レベルで、SIP トランクを介してコールを IP Phone D に発信します。

    3. オーディオのメディアが、両方のコールに対して正常に確立されます。

    4. A から B のコールが、IP Phone B によりビデオ コールにエスカレートされます。 ビデオ接続が正常に確立されます。

    5. C から D のコールが、IP Phone D によりビデオ コールにエスカレートされます。 メディアが、C から D のコールのビデオに接続されます。C から D のビデオ コールで使用できる帯域幅が十分にないので、A から B のコールはプリエンプション処理されません。

    6. フロー制御が発生し、C と D との間のコールはオーディオ コールとして設定されます。


    (注)  


    オーディオの帯域幅は、ビデオへのエスカレート試行中にリリースされます。 プリエンプションが不可の場合は、フロー制御が実行されます。 この時点でオーディオ帯域幅が使用できない場合、オーディオ帯域幅はオーバーサブスクライブになります。


    例 25

    この例では、新しいビデオ コールには、384 K の帯域幅が必要で、既存のビデオ コールには、384 K の帯域幅が予約されています。 ロケーション A では、最大で 384 K のビデオ帯域幅および 300 K のオーディオ帯域幅を使用できます。

    SIP トランクは、ロケーション A にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、コールを IP Phone B に発信します。

    2. IP Phone C が、プライオリティ優先レベルで、SIP トランクを介してコールを IP Phone D に発信します。

    3. オーディオのメディアが、両方のコールに対して正常に確立されます。

    4. A から B のコールが、IP Phone B によりビデオ コールにエスカレートされます。 ビデオ接続が正常に確立されます。

    5. C から D のコールが、IP Phone D によりビデオ コールにエスカレートされます。 メディアが、C から D のコールのビデオに接続されます。C から D のコールと同じ優先レベルなので、A から B のコールはプリエンプション処理されません。

    6. C から D のビデオ コールの帯域幅が十分にないので、フロー制御が発生し、C と D の間のコールはオーディオ コールとして設定されます。

    例 26

    この例では、ビデオ コールに 384 K の帯域幅が必要です。 ロケーション A では、最大で 200 K のビデオ帯域幅および 200 K のオーディオ帯域幅を使用できます。

    SIP トランクは、ロケーション A にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、コールを IP Phone B に発信します。

    2. オーディオのメディアが正常に確立されます。

    3. A から B のコールが、IP Phone B によりビデオ コールにエスカレートされます。 メディアが、A から B のコールのビデオに接続されます。A から B のビデオ コールの帯域幅が十分にないので、プリエンプション処理されるコールはありません。 フロー制御が発生し、A と B との間のコールはオーディオ コールとして設定されます。

    例 27

    この例では、各ビデオ コールに 384 K の帯域幅が必要です。 この例には、2 種類のロケーションが存在します。

    • ロケーション A

    • ロケーション B

    ロケーション A では、最大で 1500 K のビデオ帯域幅および 400 K のオーディオ帯域幅を使用できます。

    ロケーション B では、最大で 400 K のビデオ帯域幅および 400 K のオーディオ帯域幅を使用できます。

    IP Phone A、C および F は、クラスタ 1 にあります。

    IP Phone B および D は、クラスタ 2 のロケーション A にあります。

    IP Phone B には、クラスタ 2 のロケーション B の共有回線 B1 があります。

    IP Phone E は、クラスタ 2 のロケーション B にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、フラッシュ優先レベルで、SIP トランクを介して、ビデオ コールを IP Phone B に発信します。 コールが対応され、ビデオが正常に確立されます。 IP Phone C が、プライオリティ優先レベルで、SIP トランクを介してビデオ コールを IP Phone D に発信します。

    2. C から D および A から B のビデオ コールがアクティブになります。

    3. IP Phone F は、プライオリティ優先レベルで、SIP トランクを介して、IP Phone E に対してビデオ コールを発信します。 F および E 間のビデオ コールがアクティブになります。

    4. IP Phone B が、コールを保留し、A から B のコールのビデオが停止します。

    5. B1(共有回線)は、フラッシュ優先レベルでコールを再開します。

    6. A から B1 のコールより優先レベルが低いので、F から E のコールがプリエンプション処理されます。 F から E のコールがクリアされます。

    7. A から B1 のコールがアクティブになります。

    例 28

    この例では、各ビデオ コールに 384 K の帯域幅が必要です。 ロケーション A では、最大で 500 K のビデオ帯域幅および 500 K のオーディオ帯域幅を使用できます。

    IP Phone A、C および E は、ロケーション A にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、オーディオ コールを IP Phone B に発信します。 コールが対応され、A から B のオーディオ コールがアクティブになります。

    2. IP Phone C が、プライオリティ優先レベルで、SIP トランクを介してビデオ コールを IP Phone D に発信します。

    3. C から D のコールがアクティブになります。

    4. IP Phone A が、IP Phone E にコールを転送します(フラッシュ コール)。

    5. IP Phone E が、コールに対応します。 IP Phone A が、転送を完了して、B から E のビデオ コールが設定されます(フラッシュ優先レベル)。

    6. C から D のコールがプリエンプション処理されます。

    7. B から E のビデオ コールがアクティブになります。

    例 29

    この例では、各ビデオ コールに 384 K の帯域幅が必要です。 ロケーション A では、最大で 500 K のビデオ帯域幅および 500 K のオーディオ帯域幅を使用できます。

    IP Phone A、C および E は、ロケーション A にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ優先レベルで、SIP トランクを介して、オーディオ コールを IP Phone B に発信します。 コールが対応され、A から B のオーディオ コールがアクティブになります。

    2. IP Phone C が、プライオリティ優先レベルで、SIP トランクを介してビデオ コールを IP Phone D に発信します。

    3. C から D のコールがアクティブになります。

    4. IP Phone A が、IP Phone E にコールを転送します(フラッシュ コール)。

    5. IP Phone E が、コールに対応します。 IP Phone A が、転送を完了して、B から E のビデオ コールが設定されます(フラッシュ優先レベル)。

    6. C から D のコールがプリエンプション処理されます。

    7. B から E のビデオ コールがアクティブになります。

    例 30

    この例では、各ビデオ コールに 384 K の帯域幅が必要です。 ロケーション A では、最大で 800 K のビデオ帯域幅および 500 K のオーディオ帯域幅を使用できます。

    IP Phone A、C および E は、ロケーション A にあります。

    次の一連のイベントが順に発生します。

    1. IP Phone A が、プライオリティ ビデオ コールを IP Phone B に発信します。 IP Phone B がコールに対応し、ビデオが確立されます。

    2. IP Phone C が、フラッシュ ビデオ コールを IP Phone D に発信します。 IP Phone D がコールに対応し、ビデオが確立されます。

    3. IP Phone A が、A から B のコールを保留します。 この時点では、A から B のビデオ コールのビデオ プールには、帯域幅は解放されません。

    4. IP Phone E が、フラッシュ ビデオ コールを IP Phone F に発信します。

    5. ロケーション A に十分な帯域幅がないので、A から B のコールがプリエンプション処理されます。

    6. E から F のビデオ コールがアクティブになります。

    例 31

    次の一連のイベントが順に発生します。

    1. IP Phone A が IP Phone B にコールし、IP Phone B がコールに対応します。

    2. IP Phone B が、IP Phone C に打診転送します。

    3. IP Phone B が転送を完了します。

    設定

    Location-based Maximum Bandwidth Enforcement Level for MLPP Calls サービス パラメータは [Strict] に設定され、Location Based MLPP Pre-emption サービス パラメータは [True] に設定されています。

    ロケーション 1(Loc1)およびロケーション 2(Loc2)間のコールでは、80 K の帯域幅が必要です。

    ロケーション 2(Loc2)およびロケーション 3(Loc3)間のコールでは、24 K の帯域幅が必要です。

    ロケーション 1(Loc1)およびロケーション 3(Loc3)間のコールでは、80 K の帯域幅が必要です。

    ロケーション

    使用可能な合計帯域幅

    Loc1

    160 K

    Loc2

    160 K

    Loc3

    24 K

    手順 1 の後、IP Phone A と IP Phone C の間のコールに必要な帯域幅は、80 K ですが、使用できる帯域幅は、24 K だけです。 Cisco Unified Communications Manager 8.6(1) 以降では、Location-based Maximum Bandwidth Enforcement Level for MLPP Calls サービス パラメータが [Strict] に設定され、Location Based MLPP Pre-emption サービス パラメータが [True] に設定されている場合、コールがクリアされます。

    例 32

    次に、複数のコールがプリエンプション処理されるが、新しいコールが失敗する例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    フラッシュ優先レベルのコール 1。アラートを発生し、LOC-BR1 で 24 kbps(G.729)を使用します。

    フラッシュ優先レベルのコール 2。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    フラッシュ優先レベルのコール 3。アラートを発生し、LOC-BR1 で 80 kbps(G.711)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    次の一連のイベントが順に発生します。

    1. ロケーション LOC-BR1 のオーディオ帯域幅が 10 kbps に変更されます。

    2. IP Phone B が、IP Phone Y をコールしようとします。

    3. LOC-BR1 のオーディオ帯域幅がオーバーサブスクライブの場合、コール 1 ~コール 3 がプリエンプション処理されます。

    4. プリエンプション処理の後、IP Phone B と IP Phone & との間の新しいコールを完了する帯域幅が十分にないので、新しいコールは拒否されます。


    (注)  


    新しいコールは、ルーチン優先レベルのコールの場合もあります。 この場合、ルーチン優先レベル コールは、上位優先レベルの複数のコールをプリエンプション処理し、プリエンプション トーンが再生されます。


    例 33

    次に、複数のコールがプリエンプション処理され、新しいコールが正常に発信される例について説明します。

    設定

    ロケーション(LOC-BR1)の合計オーディオ帯域幅は 140 kbps です。

    地域コーデックは、最大オーディオ ビット レート 64 kbps を指定します。

    LOC-BR1 には、次のコールが含まれます。

    フラッシュ優先レベルのコール 1。アラートを発生し、LOC-BR1 で 24 kbps(G.729)を使用します。

    フラッシュ優先レベルのコール 2。アラートを発生し、LOC-BR1 で 16 kbps(G.728)を使用します。

    フラッシュ優先レベルのコール 3。アラートを発生し、LOC-BR1 で 80 kbps(G.711)を使用します。

    IP Phone B は、ロケーション Hub None にあり、IP Phone Y は、ロケーション LOC-BR1 にあります。

    次の一連のイベントが順に発生します。

    1. ロケーション LOC-BR1 のオーディオ帯域幅が 80 kbps に変更されます。

    2. IP Phone B が、エクゼクティブ オーバーライド優先レベルで、IP Phone Y をコールしようとします。

    3. LOC-BR1 のオーディオ帯域幅がオーバーサブスクライブの場合、コール 3 がプリエンプション処理されます。

    4. プリエンプション処理後、IP Phone B および IP Phone Y の間の新しいコールの完了に使用できる帯域幅が十分にないので、コール 1 および 2 がプリエンプション処理されます。

    5. 新しいコールの通過が許可されます。

    MLPP アナウンス

    この項では、特別な MLPP アナウンスについて説明します。 MLPP 優先コールの試行が失敗したユーザは、優先コールがブロックされた理由を説明する各種のアナウンスを受信します。

    許可されていない優先レベルの使用アナウンス

    ユーザは、自分の回線に許可された最高の優先レベルよりも高い優先レベルのコールをかけようとすると、許可されていない優先レベルの使用アナウンスを受信します。 ユーザは、自分に権限のない発信パターンを使用して優先コールをダイヤルしたときに、許可されていない優先レベルの使用アナウンスを受信します。

    Cisco Unified Communications Manager は、パターンと一致してコールをブロックする理由が示されたコールの試行をブロックするように特定のパターンまたはパーティションが設定されている場合だけ、Precedence Level Exceeded の条件を認識します。

    許可された発信パターンを割り当てるには、Cisco Unified Communications Manager の管理ページの [ルートパターンの設定(Route Pattern Configuration)] ウィンドウまたは [ハントパイロットの設定(Hunt Pilot Configuration)] ウィンドウと [トランスレーションパターンの設定(Translation Pattern Configuration)] ウィンドウを使用します。 MLPP Precedence Level Exceeded の条件を設定するには、Cisco Unified Communications Manager の管理ページで、[ルートパターンの設定(Route Pattern Configuration)] ウィンドウまたは [ハントパイロットの設定(Hunt Pilot Configuration)] ウィンドウと [トランスレーションパターンの設定(Translation Pattern Configuration)] ウィンドウの [ルートオプション(Route Option)] フィールドを使用して [このパターンをブロック(Block this pattern)] オプションを選択します。 ドロップダウン リスト ボックスで、[優先レベルの超過(Precedence Level Exceeded)] を選択します。 詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

    以下の図に、許可されていない優先レベルの使用アナウンスを受信するユーザの例を示します。

    図 28. 許可されていない優先レベルの使用アナウンスの例

    この例では、ユーザ 1002 が優先コールを開始するために 90 をダイヤルします。 9 は優先順位アクセス番号を示し、0 はユーザが使おうとしている優先レベルを示します。 このユーザはフラッシュ オーバーライド優先コール(優先レベル 0 のコール)を許可されていないので、ユーザは許可されていない優先レベルの使用アナウンスを受信します。

    ブロックされた優先権アナウンス

    優先コールの宛先がオフフックである場合や、宛先が同等かそれ以上の優先順位の優先コールで通話中で、コール待機機能も自動転送機能もなく、Alternate Party Diversion(APD)の発信先も指定されていない場合、あるいは共通ネットワーク リソースがない場合、ユーザはブロックされた優先権アナウンスを受信します。

    以下の図は、ブロックされた優先権アナウンスの例を示しています。

    図 29. ブロックされた優先権アナウンスの例

    この例では、ユーザ 1000 が 90-1001 をダイヤルしてユーザ 1001 に優先コールをかけます。 ユーザ 1001 は、オフフックまたは同等以上の優先レベルの優先コールで通話中であり、コール待機機能も自動転送機能もなく、Alternate Party Diversion の発信先も指定されていないため、ユーザ 1000 はブロックされた優先権アナウンスを受信します。

    プリエンプションに対応していないビジー状態のステーション

    ユーザは、ダイヤルした番号がプリエンプション対応ではない場合に、このアナウンスを受信します。 つまり、ダイヤルした番号が通話中で、コール待機機能や自動転送機能がなく、Alternate Party Diversion の発信先も指定されていない場合です。

    クラスタ間トランクを経由したアナウンス

    次の図に、クラスタ間トランクを経由して配信される MLPP アナウンスの例を示します。

    図 30. クラスタ間トランクを経由した MLPP アナウンスの例

    この例では、クラスタ間トランクが接続する 2 つのクラスタ上に電話機 1000 と 2000 が存在します。 ユーザ 2000 には、コール待機や自動転送などの機能は設定されていません。

    次の一連のイベントが順に発生します。

    1. ユーザ 2000 は、電話機をオフフックしてダイヤルを開始します (ユーザ 2000 のステータスは発信側ビジーとプリエンプション非対応が指定されています)。

    2. ユーザ 1000 はクラスタ間トランク経由でユーザ 2000 に優先コールをダイヤルします。 ユーザ 2000 は通話中であり、プリエンプション対応ではないため、コールは拒否されます。

    3. ユーザ 1000 が優先コールを発信したため、コールは優先処理を受信し、リモート クラスタ上のアナウンス サーバは適切なブロックされた優先権アナウンス(BPA)をスイッチ名とクラスタのロケーションとともにユーザ 1000 に送信します。

    セキュアな(暗号化された)アナウンスおよび保留音

    Cisco Unified Communications Manager 8.6(1) 以降では、アナンシエータおよび保留音(MOH)の Secure Real-Time Protocol(SRTP)がサポートされます。 アナウンスまたは MOH がユーザに再生される場合、Cisco Unified Communications Manager は、アナンシエータと MOH およびユーザのデバイスのセキュリティ機能をチェックします。 すべてのデバイスが SRTP をサポートする場合、アナウンスまたは MOH メディアが、ユーザのデバイスへのストリーミングの前に暗号化され、セキュアなロック アイコンが Cisco Unified IP Phone に表示されます。

    優先コール向けにセキュアおよび非セキュアなアナウンスが挿入された場合のロック アイコンの表示例については、クラスタ間トランクを経由したアナウンスを参照してください。 優先コール向けにセキュアおよび非セキュアな MOH メディアが挿入された場合のロック アイコンの表示例については、保留音 を参照してください。

    優先順位パターン用の MLPP 番号計画アクセス制御

    MLPP は、ユーザに対して定義されたコーリング サーチ スペースとパーティションを使用して MLPP コールを認証および検証し、優先順位パターンにアクセス制御を提供します。


    (注)  


    この使用方法の例外は、AS-SIP エンドポイントです。 AS-SIP はダイヤルされた番号を使用して優先順位を通知せず、優先順位の認証を確立するために別のプロトコル メカニズムを使用します。 この項の内容は、AS-SIP 電話機を除くすべての MLPP デバイスに適用されます。

    ユーザの最高優先順位は、ユーザ設定時に設定されます。 MLPP 機能を備えたすべてのステーション デバイスが、MLPP 対応または MLPP 非対応として設定されます。 ユーザ プロファイルが適用されるデバイスは、そのデバイスから開始される優先コールに関して、そのユーザの優先レベルを継承します。 デフォルト ユーザが割り当てられたデバイスは、デフォルト ユーザの標準優先レベルを継承します。

    発呼側に関連付けられたコーリング サーチ スペース(CSS)の設定によって、ユーザが優先順位パターンをダイヤル(優先コールを発信)できるかどうかが制御されます。 Cisco Unified Communications Manager には、許可される最高の優先順位値を明示的に示す設定はありません。

    次の例に、第 3 のユーザにプライオリティ レベルの優先コールをかけようとする 2 人のユーザについて、優先コールへのアクセスの違いを示します。

    以下の図に、優先順位パターン用の MLPP 番号計画アクセス制御の例を示します。

    図 31. 優先順位パターン用の MLPP 番号計画アクセス制御の例

    次の表で、この例の 3 人のユーザを定義します。

    ユーザ

    電話番号(DN)

    パーティション

    コーリング サーチ スペース(CSS)

    General

    1000

    Routine

    Flash Override

    Major

    2000

    Routine

    Priority

    Private

    3000

    Routine

    Routine

    この例では、パーティションとコーリング サーチ スペースを使用して優先コールへのアクセスを制御する方法を示します。

    Private 3000 が優先順位パターン 93 をダイヤルして優先コールをかけると、次のイベントが発生します。

    • コール処理は、Private 3000 のコーリング サーチ スペースを検索し、Routine CSS を検出します。

    • Private 3000 の Routine CSS 内で、コール処理は Block Priority パーティションを検出します。

    • Block Priority パーティションで、コール処理はパターン 93 を検出し、トランスレーション パターン 93 に移動します。

    • トランスレーション パターン 93 は、優先コールがこのユーザ(DN)に対してブロックされることを決定し、コール処理は許可されていない優先レベルの使用アナウンス(UPA)を発行します。

    Major 2000 が番号 931000 をダイヤルして優先コールをかけると、次のイベントが発生します。

    • コール処理は、Major 2000 のコーリング サーチ スペースを検索し、Priority CSS を検出します。

    • Major 2000 の Priority CSS 内で、コール処理は Priority パーティションを検出します。

    • Priority パーティションで、コール処理はパターン 93.XXXX を検出し、トランスレーション パターン 93.XXXX に移動します。

    • トランスレーション パターン 93.XXXX は、優先コールがこのユーザ(DN)に対して許可されることを決定します。 したがって、コール処理は、ユーザ General 1000 へのプライオリティ レベルの優先コールを実行します。

    MLPP トランク選択

    MLPP トランク選択では、ルート リストとルート グループを使用して使用可能なトランクのハントが実行されます。 Cisco Unified Communications Manager の管理ページでは、単一のダイヤル パターンを介して複数のゲートウェイにコールをルーティングし、使用可能なチャネルを検索するようにルート リストおよび関連するルート グループを設定することができます。 ルート リストには、ルート リストがコールをルーティングできる多数のトランク リソースがありますが、個々のリソースは多数のゲートウェイに分散している場合があります。

    ゲートウェイの集合(つまり、ルート リストとルート グループの設定)で使用可能なトランク リソースを特定できない場合、Cisco Unified Communications Manager は、集合内で優先レベルの低い共有リソースのプリエンプションの開始を試みます。 ルート リストとルート グループの設定でプリエンプション対応のチャネルをさらに検索する方法は 2 つあります。

    方法 1

    ルート リストおよび単一のルート グループを設定します。 ルート グループにトランク インターフェイス(ゲートウェイ)を追加し、Direct Route ゲートウェイをルート グループ内の最初のゲートウェイとして位置決めします。 ルート グループをルート リストに関連付け、Top Down 分散アルゴリズムを選択します。 この設定を使用して、システムはまずルート グループ内のすべてのゲートウェイでアイドル状態のチャネルを検索します。 ルート グループ内のどのゲートウェイにもアイドル状態のチャネルがない場合は、次のように、ルート グループ内の最初のゲートウェイ(つまり、Direct Route ゲートウェイ)で優先的なトランク選択が開始されます。

    • コール処理は、分散アルゴリズムに基づいて集合から現在のルートを選択し、ゲートウェイ デバイスがプリエンプションを開始できるかどうかを判別するために、このゲートウェイ デバイスへコールを発信します。

    • 現在のゲートウェイ デバイスが優先コール要求を拒否した場合(つまり、ゲートウェイ デバイスがプリエンプションを開始できない場合)、コール処理は集合内の次のゲートウェイを現在のルートとして選択し、ゲートウェイ デバイスがプリエンプションを開始するか、ルート リストとルート グループの集合内のすべてのゲートウェイ デバイスが検索されるまで、この手順を続行します。

    方法 2

    使用可能なルート(トランク インターフェイス)ごとに、ルート リストおよび個別のルート グループを設定します。 1 つのルート グループを Direct ルート グループとして指定し、残りのルート グループを Alternate ルート グループとして指定します。 Direct Route トランク インターフェイス(ゲートウェイ)を Direct ルート グループの唯一のメンバとして追加します。 Alternate Route ゲートウェイを個々の Alternate ルート グループに追加します。 ルート グループをルート リストに関連付け、Direct ルート グループをルート リスト内の最初のルート グループとして設定し、ルート グループの関連付けごとに Top Down 分散アルゴリズムを選択します。

    この設定を使用して、まず Direct ルート グループ内の Direct ゲートウェイでアイドル状態のチャネルが検索されます。 Direct ゲートウェイ内にアイドル状態のチャネルがない場合、システムは次のように、この Direct ゲートウェイに対して優先的なトランク選択を開始します。

    • コール処理は、Direct ルートを選択し、このゲートウェイ デバイスにコールを発信して、ゲートウェイ デバイスがプリエンプションを開始できるかどうかを判別します。

    • Direct ゲートウェイ デバイスが優先コール要求を拒否した場合(つまり、ゲートウェイ デバイスがプリエンプションを開始できない場合)は、ルート リスト内の次のルート グループが現在のルートとして選択されます。 現在のゲートウェイでアイドル状態のチャネルが見つかるか、現在のゲートウェイ デバイスがプリエンプションを開始するか、ルート リストとルート グループの集合内のすべてのゲートウェイ デバイスが検索されるまで、この手順が続行されます。

    次の例は、フラッシュ レベルの着信優先コールが使用可能なトランク デバイスを探している場合に、使用可能なトランク デバイスを検索する 2 つの方法を示しています。

    以下の図に、ルート リストとルート グループを使用して使用可能なトランク デバイスをハントする MLPP トランク選択の例を示します。

    図 32. MLPP トランク選択(ハント)の例

    方法 1 では、次の一連のイベントが発生します。

    1. フラッシュ レベルの着信優先コールがルート リスト RL に到達します。これには、ルート グループ RG1 だけが含まれています。

    2. ルート グループ RG1 には 3 つのトランク デバイスが含まれています。

      RG1 内の 3 つのトランク デバイスのうち、トランク デバイス 1 とトランク デバイス 2 は通話中なので、システムは使用可能なトランク デバイス 3 にコールを発信します。

      方法 2 では、次の一連のイベントが発生します。

    3. フラッシュ レベルの着信優先コールがルート リスト RL に到達し、まずルート グループ RG1 へ移動します。ここで、コールはトランク デバイス 1 へ送信されますが、トランク デバイス 1 は通話中です。

      トランク デバイス 1 の場合、このデバイスを使用しているコールを差し替えるには、フラッシュよりも優先順位の高いコールである必要があります。

    4. コールはルート リスト RL 内で次のルート グループを探し、ルート グループ RG2 を検出します。 ルート グループ RG2 にはトランク デバイス 2 が含まれています。これも通話中ですが、プライオリティよりも優先レベルの高い優先コールであれば、トランク デバイス 2 でプリエンプションを実行できます。

      このコールの方が優先順位が高いので、トランク デバイス 2 の既存のコールが差し替えられます。

    MLPP 階層設定

    デバイスの MLPP 設定は次の階層に従っています。

    • デバイスの [MLPP通知(MLPP Indication)] が [オフ(Off)] に設定されている場合、デバイスは MLPP コールのインジケータを送信できません。 デバイスの [MLPPプリエンプション(MLPP Preemption)] が [無効(Disabled)] に設定されている場合、デバイスはコールを差し替えることができません。 これらの設定は、デバイスの共通デバイス設定項目を上書きします。

    • デバイスの [MLPP通知(MLPP Indication)] が [オン(On)] に設定されている場合、デバイスは MLPP コールのインジケータを送信できます。 デバイスの [MLPPプリエンプション(MLPP Preemption)] が [強制(Forceful)] に設定されている場合、デバイスはコールを差し替えることができます。 これらの設定は、デバイスの共通デバイス設定項目を上書きします。

    • デバイスの [MLPP通知(MLPP Indication)] が [デフォルト(Default)] に設定されている場合、デバイスはそのデバイスの共通デバイス設定から、MLPP コールのインジケータの送信の設定を継承します。 デバイスの [MLPPプリエンプション(MLPP Preemption)] が [デフォルト(Default)] に設定されている場合、デバイスは共通デバイス設定から、コールの差し替えの設定を継承します。

    共通デバイス設定の MLPP 設定は次の階層に従っています。

    • 共通デバイス設定の [MLPP通知(MLPP Indication)] が [オフ(Off)] に設定されている場合、共通デバイス設定内のデバイスは MLPP コールのインジケータを送信できません。 共通デバイス設定の [MLPPプリエンプション(MLPP Preemption)] が [無効(Disabled)] に設定されている場合、共通デバイス設定内のデバイスはコールを差し替えることができません。 これらの設定は、MLPP エンタープライズ パラメータ設定を上書きします。

    • 共通デバイス設定の [MLPP通知(MLPP Indication)] が [オン(On)] に設定されている場合、共通デバイス設定内のデバイスは MLPP コールのインジケータを送信できます。 共通デバイス設定の [MLPPプリエンプション(MLPP Preemption)] が [強制(Forceful)] に設定されている場合、共通デバイス設定内のデバイスはコールを差し替えることができます。 これらの設定は、MLPP エンタープライズ パラメータ設定を上書きします。

    • 共通デバイス設定の [MLPP通知(MLPP Indication)] が [デフォルト(Default)] に設定されている場合、デバイスは MLPP Indication Status エンタープライズ パラメータから、MLPP コールのインジケータの送信の設定を継承します。 共通デバイス設定の [MLPPプリエンプション(MLPP Preemption)] が [デフォルト(Default)] に設定されている場合、共通デバイス設定は MLPP Preemption Setting エンタープライズ パラメータから、コールの差し替えの設定を継承します。

    MLPP Indication Status エンタープライズ パラメータは、エンタープライズ内の共通デバイス設定および共通デバイス設定のインジケータ ステータスを定義しますが、共通デバイス設定および個々のデバイスのデフォルト以外の設定でその値を上書きできます。 このエンタープライズ パラメータのデフォルト値は、[MLPP Indication turned off] です。

    MLPP Preemption Setting エンタープライズ パラメータは、エンタープライズ内のデバイスおよび共通デバイス設定のプリエンプション機能を定義しますが、共通デバイス設定および個々のデバイスのデフォルト以外の設定でその値を上書きできます。 このエンタープライズ パラメータのデフォルト値は、[No preemption allowed] です。

    MLPP Domain Identifier エンタープライズ パラメータは、MLPP ドメインを指定します。 MLPP サービスはドメインだけに適用されます。つまり、特定のドメインに属す加入者と、ネットワークおよびアクセス リソースだけに適用されます。 MLPP 加入者からのコールに属す接続とリソースには、優先レベルと MLPP ドメイン識別子のマークが付けられます。 同じドメイン内の MLPP ユーザからの優先順位の高いコールだけが、同じドメイン内の優先順位の低いコールを差し替えることができます。

    サービス パラメータの特別なトレース設定

    MLPP は、トレース用のサービス パラメータを発行します。

    詳細については、『Cisco Unified Serviceability Administration Guide』を参照してください。

    優先コール用の CDR の録音

    MLPP 優先コールは、呼詳細レコード(CDR)を生成します。 CDR は、優先コールの優先レベルを示します。

    通常は、同じ優先レベルのコール レッグが適用されます。 転送コールや会議コールでは優先レベルが異なる場合があるので、Cisco Unified Communications Manager CDR はコールの各レッグの優先レベルを示します。

    Cisco Unified Communications Manager CDR は、差し替えられたコールの切断のプリエンプション値を記録します。

    詳細については、『Cisco Unified Serviceability Administration Guide』を参照してください。

    回線機能のインタラクション

    この項では、MLPP と回線機能とのインタラクションの仕組みについて説明します。

    自動転送

    MLPP は、次のリストで説明しているように、自動転送機能と通信します。

    • コールの話中転送

      • オプションで、任意の MLPP 対応ステーションに対して事前設定の Precedence Alternate Party ターゲットを設定できます。

      • Cisco Unified Communications Manager は、コールに Precedence Alternate Party Diversion 手順を適用する前に、通常の方法で優先コールを転送する話中転送機能を適用します。

      • 着信優先コールの優先順位が既存のコールの優先順位と同じかそれより低い場合、コール処理は通常の自動転送機能を呼び出します。

      • 優先コールの宛先ステーションがプリエンプション対応ではない場合(つまり、MLPP が設定されていない場合)、コール処理は自動転送機能を呼び出します。

      • システムは、転送された複数のコール間でのコールの優先順位を保存します。

      • 着信優先コールの優先順位が既存のコールの優先順位より高い場合は、プリエンプションが実行されます。 優先コールが送信されたステーションの電話が切られるまで、アクティブなコールによって差し替えられるコールの両方のユーザに、連続的なプリエンプション トーンが再生されます。 電話を切ると、優先コールが送信されたステーションに優先順位呼び出し音が再生されます。 宛先ステーションは、オフフックになると、優先コールに接続されます。

    • コールの無応答時転送

      • コールの優先レベルがプライオリティ以上である場合、コール処理は、自動転送プロセスでコールの優先レベルを保存し、転送先のユーザの差し替えを試みます。

      • 優先コールの宛先に対して Alternate Party が設定されている場合、コール処理は、Precedence Call Alternate Party タイムアウトの期限が切れた後に、優先コールを代替パーティに転送します。

        優先コールの宛先に対して Alternate Party が設定されていない場合、コール処理は、優先コールを無応答時転送(CFNA)設定に転送します。

      • 優先コールは通常、ボイスメール システムではなくユーザにルーティングされます。 管理者は、優先コールがボイスメール システムに転送されるのを避けるため、Use Standard VM Handling For Precedence Calls エンタープライズ パラメータを設定します。 詳細については、MLPP のエンタープライズ パラメータの設定を参照してください。

    コール転送

    MLPP は、コール転送機能と通信します。 ブラインド転送と打診転送の場合は、コンサルト コールも含め、転送されるコールの各接続が、コールが確立されたときに接続に割り当てられた優先順位を維持します。

    共有回線

    MLPP は、共有回線と通信します。 保留中のコールがある共有回線アピアランスは、同じ電話番号(DN)を持つ別の端末への優先順位の高いコールを確立するため、差し替えられる可能性があります。 この場合、保留中の元のコールは切断されず、優先コールが接続されます。 優先コールが終了すると、ユーザは保留中の元のコールを取得できます。

    コール待機

    MLPP は、次のリストで説明しているように、コール待機機能と通信します。

    • コール待機が設定されているアクティブ コールをすでに複数持つ宛先ステーションに対してルーチン優先レベルのコールが発信された場合、存在するコール数がビジー トリガーより小さいと、通常のコール待機がアクティブになります。

    • コール待機が設定されているアクティブ コールを 1 つ持つ宛先ステーションにルーチン以外の優先レベルのコールが発信された場合、存在するコール数がビジー トリガーより小さく、以下のいずれかの条件があてはまると、優先コール待機がアクティブになります。

      • デバイスが視覚的なコール アピアランスをサポートしており、1 つのオープン アピアランスを持っている。

      • デバイスが視覚的ではない 2 つのコール アピアランスをサポートしており、1 つのオープン アピアランスを持っている。さらに、新しいコールの優先順位が既存のコール以下である。

      • デバイスが 1 つの(視覚的または非視覚的な)オープン アピアランスを持っており、デバイスがプリエンプション非対応である。

    • コール待機が設定されたアクティブ コールを 1 つ持つ宛先ステーションに対してルーチン以外の優先レベルのコールが発信された場合、存在するコール数がビジー トリガー以上であると、優先順位が低い既存のコールがプリエンプション処理されます。

    コールの保存

    Cisco Unified Communications Manager コール保存機能によって保存される MGCP トランク コールまたは接続は、コール保存機能が呼び出された後、優先レベルと MLPP ドメインを保存します。 デバイスを Cisco Unified Communications Manager に登録すると、システムは、保存されたコールを Cisco Unified Communications Manager システムのデバイス層だけに保存します。 そのため、保存されたコールは 2 つの半々のコールとして扱われます。 これらのデバイスでプリエンプションが実行された場合、一方のレッグだけが他方のレッグへのプリエンプション プロトコルに従うことができます。 システムは、RTP ポートのクローズによってしかコールの終了を検知できません。

    自動代替ルーティング

    AAR の拡張機能である Automated Alternate Routing (AAR) for Insufficient Bandwidth 機能は、ロケーションの帯域幅が不十分で Cisco Unified Communications Manager がコールをブロックした場合に、代替番号を使用し、Public Switched Telephone Network(PSTN)またはその他のネットワークを介してコールを再ルーティングするため、自動的にフォールバックするメカニズムを提供します。 この機能を使用すると、発信者は電話を切ったり着信側に再びダイヤルしたりする必要がなくなります。

    優先コールの試みが AAR サービスの起動条件と一致した場合、優先コールは AAR 設定の指定に従い、PSTN またはその他のネットワークを介して再ルーティングされます。 Cisco Unified Communications Manager は、コールがルーティングされたネットワーク インターフェイスの MLPP 通知対応および MLPP プリエンプション対応の設定に基づいて、コールが最初から PSTN またはその他のネットワークを介してルーティングされた場合と同じように、コールの優先順位を処理します。

    自動代替ルーティングの設定の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。

    MGCP と PRI プロトコル

    MLPP は、Cisco Unified Communications Manager が MGCP プロトコルを使用して制御し、MLPP プリエンプション対応として設定されたターゲット Voice over IP ゲートウェイ上の T1-CAS および T1-PRI(北米)インターフェイスに対してだけ、共通ネットワーク ファシリティ プリエンプションをサポートします。

    セキュアなエンドポイントとセキュアな通信

    米国国防総省(DOD)の TDM ネットワークでは、従来のアナログ Secure Telephone Unit(STU)と BRI Secure Telephone Equipment(STE)をセキュアなエンドポイントとして使用しています。これらはセキュアな通信には重要です。 IP STE でも、従来の設備の必要性を削減するためのサポートが必要です。 Cisco Unified Communications Manager はこれらのデバイスの Skinny Client Control Protocol をサポートしています。 モデム リレーは、従来の V.150 または V.150.1 Minimal Essential Requirements(MER)プロトコルのいずれかを使用しており、セキュアな通信を提供しています。


    (注)  


    トランクで V.150.1 Modem over IP(MOIP)コールをサポートするには、ゲートウェイの Digital Access PRI/T1 ポート設定の Cisco Unified Communications Manager 管理ページの [V150(サブセット)(V150 (subset))] チェックボックスをオンにする必要があります。 また、mgcp package-capability mdste-package CLI コンフィギュレーション コマンドを使用して、ゲートウェイの MDSTE パッケージを有効にする必要もあります。 詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。


    MLPP 優先順位と DSCP 値のマッピング

    Cisco Unified Communications Manager は、IP ネットワーク内のコールに優先順位を付けるために、MLPP 優先レベルを IP ヘッダーの ToS フィールドの DSCP 値にマッピングします。 次の優先レベルを DSCP 値にマッピングできます。

    • エクゼクティブ オーバーライド

    • フラッシュ オーバーライド
    • フラッシュ
    • 即時

    • プライオリティ

    ネットワーク内のすべての Cisco Unified Communications Manager クラスタで同一になるように、MLPP 優先レベルを DSCP 値にマッピングする必要があります。

    MLPP 優先レベルを DSCP 値にマッピングするには、サービス パラメータの [Clusterwide Parameters (System-QoS)] セクションで各優先レベルにマッピングする DSCP 値を選択します。 変更を保存するには、[保存(Save)] ボタンをクリックします。

    設定する DSCP 値は、SCCP 電話機にも適用されます。

    手順

    手順
      ステップ 1   [エンタープライズパラメータ(Enterprise Parameter)] > [MLPPパラメータ(MLPP Parameters)] を選択して、[MLPP通知(MLPP Indication)] が [オン(On)] になるように MLPP 通知ステータスを設定します。
      ステップ 2   SCCP 電話機では、[電話の設定(Phone Configuration)] > [MLPP情報(MLPP Information)] > [MLPP通知(MLPP Indication)] を選択し、[MLPP通知(MLPP Indication)] を [オン(On)] に設定します。

      前述の例で、[MLPP通知(MLPP Indication)] が [オン(On)] に設定されていない場合、オーディオ コールの DSCP に対応する DSCP 値が使用されます。

      以下の表に、Media Resource デバイスのリストおよび [MLPP優先度(MLPP Precedence)] に基づいた DSCP タギングのサポートを示します。

      表 1 Media Resource デバイスのリストおよび [MLPP優先度(MLPP Precedence)] に基づいた DSCP タギングのサポート

      Media Resource タイプ名

      ソフトウェア ベースのリソース タイプのサポート

      ハードウェア(IOS ゲートウェイ)ベースのリソース タイプのサポート

      [メディアターミネーションポイント(Media Termination Point)]

      Yes

      Yes

      [保留音(Music on Hold)]

      Yes

      No

      [アナンシエータ(Annunciator)]

      Yes

      NA

      [トランスコーダ(Transcoder)]

      NA

      Yes

      [オーディオ会議ブリッジ(Audio Conference Bridge)]

      Yes

      Yes1

      [ビデオ会議ブリッジ(Video Conference Bridge)]2

      NA

      Yes3

      1 Cisco IOS Enhanced Conference Bridge
      2 DSCP タギングは、ビデオ会議ブリッジを使用したオーディオ会議だけでサポートされる
      3 Radvision CUVC

      前述のデバイスに関する MLPP 優先コールは、対応する MLPP 優先度のサービス パラメータ ページで設定される DSCP 値を使用します。


      MLPP 補足サービス

      この項では、Cisco Unified Communications Manager の管理ページでの、MLPP 補足サービスおよびエンティティのサポートについて説明します。 各補足サービスの説明には、設定情報、推奨事項、およびトラブルシューティングの情報が記載されています。

      複数アピアランス ラインに対する MLPP サポート

      コール アピアランスが使用中ではなく、ビジー トリガーが超過していない場合、着信優先コールが表示されます。これによって、アクティブな回線が優先コール待機トーンを受信し、エンドポイント ディスプレイに適切な優先バブルが表示されます。 着信コールによって、優先順位呼び出しトーンは再生されません。 代わりに、アクティブ アピアランスで優先コール待機トーンが再生されます。

      コール アピアランスが使用中で、呼び出されたエンドポイントに自動転送が設定されていない場合、エンドポイントでは、優先順位の高い着信コールによって、低いアクティブ レベルまたは非アクティブのコール アピアランスが差し替えられます。 優先順位が同じ場合は、アクティブ アピアランスが差し替えられます。

      非アクティブ(保留中の)アピアランスが差し替えられる場合、着信コールはエンドポイント ディスプレイに適切な優先バブルを表示し、アクティブ コール アピアランスに優先コール待機トーンが表示されます。 差し替えられた他のユーザ(保留中のコールの相手側)は、コール プリエンプション トーンを受信します。

      アクティブ コール アピアランスが差し替えられる場合、通常のコール プリエンプションが実行されます(プリエンプション トーンがアクティブ アピアランスおよびもう一方のアクティブ回線に表示されます)。 既存の非アクティブ(保留中の)コール アピアランスは影響されないので、いつでも受け取ることができます。

      設定

      複数ライン アピアランスに対する MLPP サポートを正常に機能させるためには、次の設定が推奨されます。

      • 必須ではありませんが、推奨される IP Phone の設定は、最大コール数が 4 で、ビジー トリガー数が 2 です。

      • MLPP 補足サービスとのインタラクションでは、複数のパーティションを使用して、同じ DN を同じステーションに 2 回割り当てることはできません。

      • 複数のアラート コールが着信したときに、最も優先順位の高いコールに応答できないので、すべての IP Phone の [自動回線選択] オプションを無効にします。

      トラブルシューティング

      詳細なトレースが設定された CCM トレース ログを使用すると、whatToDo タグを検索することで、着信コールにプリエンプション条件がどのように適用されたかどうかを知ることができます。

      自動転送

      米国国防総省(DoD)は、携帯電話などのオフネット エンドポイントに優先コールが自動転送されることを禁止しています。 さらに、自動転送されたコールは複数の転送ホップで元の優先順位を維持する必要があります。

      不在転送(CFA)シナリオでは、優先コールは、元の着信側の MLPP Alternate Party(MAP)ターゲットにただちにルーティングされます。 CFA ターゲットは、MLPP コールでは使用されません。

      話中転送(CFB)シナリオでは、優先コールは、制限事項に記述されたホップ数の制限値に従い、着信側エンドポイントのオープン アピアランスの状態で、設定された CFB の宛先に転送されます。

      無応答時転送(CFNA)シナリオでは、コール処理が元の着信側の CFNA ターゲットに単一の転送ホップを試みます。 応答なしタイマーの期限が切れる前にエンドポイントが応答しないと、コールが元の着信側の MAP ターゲットに送信されます。

      設定

      DoD の MLPP 操作では、すべての MLPP エンドポイントに MLPP Alternate Party(MAP)ターゲットの電話番号が設定されている必要があります。 MAP は通常、アテンダントの番号を指定し、転送された MLPP コールの最後の宛先として使用されます。

      MAP が必要なときに既定の設定にエンドポイントが従っていない場合、MLPP コール発信者にリオーダー音が聞こえます。これは、着信側の設定に必要な MAP 設定が含まれていないことを示します。 この音が再生されるのは、他の転送オプションが使用不可であるか、設定されていない場合に、コールがアテンダントに転送されたときだけです。

      次に、自動転送の例について説明します。 まず、CFNA タイマーが 5 秒に設定された MLPP コールの呼び出し音が鳴ります(フラッシュ オーバーライド優先レベルで 3001 が 3003 にコールします)。 タイマーの期限が切れると、コールは元の着信側の CFNA ターゲット(3004)にリダイレクトされます。 このプロセス中、コールは優先レベル 1(フラッシュ オーバーライド)を維持します。

      三者通話

      Cisco Unified Communications Manager では、三者通話について次の要件が規定されています。

      • 三者通話の各接続では、元の優先レベルを維持する必要がある。

      • 三者通話の分割操作を実行する電話機は、異なる優先レベルが混在する場合、2 つのコールのうち高い方の優先レベルを使用する。

      Cisco Unified Communications Manager の MLPP には、会議ブリッジ リソースのプリエンプションも含まれます。 会議ブリッジが飽和状態になった場合、より高い優先順位の三者通話が新たに設定されたときに、各ストリームが差し替えられます。

      設定

      Maximum Ad Hoc Conference サービス パラメータを 3 に設定することを推奨します。 この設定は、アドホック コールを 3 人の参加者に制限します。 Cisco Unified Communications Manager はアドホック会議機能を使用して、三者通話を実装しています。

      Cisco Unified Communications Manager IP Voice Media Streaming アプリケーションを使用して、三者通話を行います。 IOS DSP ファームは MLPP のサポートに対応していないので、IOS DSP ファームを使用して会議コールを行わないでください。

      プリエンプションが行われるのは、1 つのブリッジだけです。

      MLPP の三者通話は、Cisco Unified Communications Manager のリリース 4.2 に追加された会議チェーン機能と相互運用しません。

      例 1

      この例では、A、B、および C 間の三者通話について説明します。 A はプライオリティ 4 で B をコールした後に、プライオリティ 2(フラッシュ)で C をコールして、会議を開始しています。 会議はアクティブ状態で、3 人の参加者で進められています。A はフラッシュ優先レベル、B はプライオリティ優先レベル、C はフラッシュ優先レベルです。 C が電話を切ると、A と B が同時に通常のコールに参加します。 A を、フラッシュからプライオリティにダウングレードする必要があります。

      例 2

      この例では、会議コールが既存の会議コールを差し替えます。 ブリッジを飽和状態にするために、会議ブリッジの最大ストリーム値が 3 に設定されています。 最初の三者通話は標準優先レベル(5)で A、B、および C 間で確立されます。 その後、電話機 D がユーザ E および F とともにフラッシュ優先レベル(2)で三者通話を確立します。

      コール転送

      スイッチが同じ優先レベルを持つ 2 つのセグメント間でコール転送を開始する場合、セグメントは転送時にその優先レベルを維持する必要があります。 異なる優先レベルのコール セグメント間でコール転送が行われた場合、転送を開始するスイッチは 2 つのセグメント間の高い方の優先レベルの接続にマークを付けます。

      Cisco Unified Communications Manager は、転送操作に関わるコール レッグの優先レベルをアップグレードすることで、この要件をサポートします。 たとえば、ユーザ A がプライオリティ優先レベルでユーザ B をコールします。 その後、ユーザ B は C への転送を開始して、ダイヤル時にフラッシュ優先番号をダイヤルします。 転送が完了すると、ユーザ A の優先レベルがプライオリティからフラッシュにアップグレードされます。


      (注)  


      優先レベルのアップグレードは、クラスタ間トランク(ICT)または PRI トランクなどのトランク デバイスでは機能しません。


      設定

      MLPP 転送サービスに、設定要件はありません。 この機能は MLPP が有効になったときに自動的に有効になり、電話機は [転送] ソフトキーをサポートします。

      コール ピックアップ

      Cisco Unified Communications Manager は、次の要件を含む最高の優先レベルの条件をコール ピックアップ アルゴリズムに追加します。

      • コール ピックアップ グループに無応答状態のユーザが複数存在し、それらの無応答状態のユーザが異なる優先レベルの場合、そのグループのコール ピックアップの試行では、最も優先順位の高いコールが最初に取得されます。

      • 同じ優先レベルの複数のコールの呼び出し音が同時に鳴っている場合、そのグループのコール ピックアップの試行では、呼び出し時間の最も長いコールが最初に取得されます。

      • MLPP コールのグループ ピックアップ機能がサポートされています。 操作の内容は、通常のコール ピックアップ機能と同じになります。

      • MLPP コールでは、他グループ ピックアップはサポートされていません。

      • 複数のコールが電話番号 A を呼び出している場合、ダイレクト コール パーク機能を使用して電話番号A からのコールに応答したユーザは、優先順位が最も高い着信コールに接続されます。これは、このユーザが電話番号A からのコールに応答するためにダイレクト コール パーク機能を使用するような設定がなされたと判断したためです。

      設定

      MLPP 機能のコール ピックアップには設定上の特別な考慮事項はありません。一方、MLPP コールでは他グループのピックアップはサポートされていません。

      ハント パイロットとハント リスト

      Cisco Unified Communications Manager には、ハント パイロット機能の以前の実装に対する変更内容が追加されました。 ハント パイロットとの MLPP のインタラクションが次のように変更されました。

      • ハント グループ内のすべての回線がビジーになるまで通常のハント アルゴリズム ロジックが実行されます。

      • すべての回線がビジー状態の場合、最も低い優先コールがプリエンプションに選択されます。

      • プリエンプションが実行される場合、通常の回線グループの応答なしタイマーが続行します。 このタイマーの期限が切れると、ハント グループ内で次に低いレベルの優先コールがプリエンプションに選択されます。

      次のハント アルゴリズムに対して MLPP が実装されます。

      • 優先度順

      • 最長アイドル時間

      • ラウンドロビン

      ブロードキャスト アルゴリズムが使用中の場合でも、プリエンプションは実行されます。 シスコは、ブロードキャスト アルゴリズムに対して明示的なサポートを提供しておりません。

      Cisco Unified Communications Manager では、ハント グループで複数の回線グループの設定を行うことができます。 現在の実装では、ハント グループで 1 つの回線グループだけがサポートされています。 複数の回線グループが設定されている場合でもプリエンプションは実行されますが、ハント グループに複数の回線グループが設定されている場合には最も低い優先コールをプリエンプションに選択できません。

      設定

      ハント パイロットとハント リストには、次の設定が必要になります。

      • ハント グループに 1 つのハント リストだけを設定します。 プリエンプションは、リスト内の最初のグループだけで実行されます。

      • すべてのハント グループ オプションを [次のメンバへ、ただし次のグループにはハントしない(Try next member, but do not go to next group)] に設定します。 これには、[応答なし(No Answer)]、[話し中(Busy)]、および [使用不可(Not Available)] のオプションが含まれます。

      • ハント グループ アルゴリズムを優先度順、ラウンドロビン、または最長アイドル時間に設定します。 シスコは、ブロードキャスト アルゴリズムに対するサポートは提供しておりません。

      • ハント パイロットの [個人の初期設定を使用(Use Personal Preferences)] チェックボックスをオフにします。

      • ハント パイロットの MLPP 優先度の設定に [デフォルト(Default)] を指定していることを確認します。

      • ハント リスト内のすべてのステーションを 1 つの MLPP ドメインに設定します。

      さらに、次の設定を行うことを強く推奨します。

      • Forward No Answer DN ハント パイロットを最後の DN に設定します。

      • Forward on Busy DN ハント パイロットを最後の DN に設定します。

      SCCP ゲートウェイ エンドポイントに対する補足サービス サポート

      これらの更新によって、SCCP ゲートウェイ エンドポイントに対する補足サービス サポートと SCCP ゲートウェイでの基本コールに対する MLPP サポートがまとめられます。


      (注)  


      この機能はアナログ電話機でだけサポートされています。


      補足サービス サポートの更新によって、次の機能が組み込まれます。

      • コール保留:SCCP ゲートウェイ上の MLPP とのコール保留インタラクション中に、ユーザは次の機能を利用できます。

        • プリエンプション(新しいコールの優先順位が保留中のコールおよびアクティブなコールの優先順位よりも高い場合)


      (注)  


      プリエンプションによって、保留中のコールとアクティブなコールの両方が差し替えられます。


      • 優先コール待機:SCCP ゲートウェイ上の MLPP とのコール待機インタラクション中に、ユーザは次の機能を利用できます。

        • ゲートウェイでの優先コール待機音のサポート

        • 単一のアクティブ コールの場合、優先コール待機を再生する代わりに優先順位の高い新しいコールのプリエンプション

        • 優先コールを呼び出し中の電話機では、着信コールが優先順位の低い呼び出し中のコールを差し替えます。


      (注)  


      ユーザがコール中にコール待機キャンセル機能の呼び出しを選択した場合、このことが優先コール待機の設定よりも優先されるのは、そのコールだけとなります。 コール待機キャンセル設定はこの設定を呼び出した電話機にだけ適用され、発信先の電話機には影響を及ぼしません。



      (注)  


      コール待機キャンセル機能の詳細については、『Cisco Unified Communications Manager アドミニストレーション ガイド』を参照してください。


      • Allow Call Waiting During an In-Progress Outbound Analog Call サービス パラメータ:Cisco Unified Communications Manager に追加された新しいパラメータです。 このパラメータは、発信コールにコール待機対応の SCCP ゲートウェイ アナログ電話機が使用されており、かつ、この電話機がコール待機トーンを再生できない場合に、この電話機に着信コールを表示することが、Cisco Unified Communications Manager によって許可されるかどうかを決定します。 アナログ電話機は、発信コールがアラートまたは接続の状態になるまでは、コール待機トーンを再生できない場合があります。 有効な値は、[True] または [False] です。

        • [True]:コール待機対応のアナログ電話機は、電話機のコール待機トーン再生機能に関係なく着信コールを受け、標準のコール応答時間制限が適用されます。

        • [False]:Cisco Unified Communications Manager では、これをビジー トリガー コール制限に達する通常のアナログ ライン アピアランスとして処理します。この処理には、転送アクション、トーン、またはトリガーに適用可能なその他の機能が含まれる場合があります。


      (注)  


      サービス パラメータの使用の詳細については、『Cisco Unified Communications Manager アドミニストレーションガイド』の「Configuring Service Parameters for a Service on a Server」の項を参照してください。


      Multilevel Precedence and Preemption のシステム要件

      MLPP を使用するには、Cisco Unified Communications Manager 4.0 以降が稼動している必要があります。

      Multilevel Precedence and Preemption のデバイス サポートの確認

      MLPP をサポートする IP Phone の完全なリストを作成するには、Cisco Unified Reporting アプリケーションを使用します。


      (注)  


      Multilevel Precedence and Preemption(MLPP)機能をサポートしているのは SCCP 電話機のみです。 SIP 電話機は MLPP をサポートしていません。


      Cisco Unified Reporting アプリケーションの詳細については、『Cisco Unified Reporting Administration Guide』を参照してください。

      手順
        ステップ 1   次のいずれかの方法を使用して、Cisco Unified Reporting を開始します。 Web アプリケーションへのアクセスを許可されるまで、ユーザの認証には Cisco Tomcat サービスが使用されます。 アプリケーションには次の方法でアクセスできます。
        • Cisco Unified Communications Manager の管理ページナビゲーション メニューで [Cisco Unified Reporting] を選択し、[Go] をクリックします。

        • Cisco Unified Real Time Monitoring Tool(RTMT)のメニューで [File] > [Cisco Unified Reporting] を選択します。

        • https://<サーバ名または IP アドレス>:8443/cucreports/ と入力し、認証済みのユーザ名とパスワードを入力します。

        ステップ 2   ナビゲーション バーで、[System Reports] をクリックします。
        ステップ 3   左側のカラムに表示されたレポートのリストで、[Unified CM Phone Feature List] オプションをクリックします。
        ステップ 4   [Generate a new report] リンクをクリックして新規レポートを生成するか、または、レポートがすでに存在する場合は、[Unified CM Phone Feature List] リンクをクリックします。
        ステップ 5   MLPP のコール優先順位がサポートされているすべての IP Phone のレポートを生成するには、各ドロップダウン リスト ボックスから次の設定を選択し、[Submit] ボタンをクリックします。

        [Product]:[All]

        [Feature]:[Call Precedence (for MLPP)]

        [List Features] ペインに、MLPP 機能をサポートするすべてのデバイスのリストが表示されます。 カラムの見出し([Product] または [Protocol])の隣にある上下の矢印キーをクリックして、リストをソートできます。

        ステップ 6   MLPP のコール プリエンプションがサポートされているすべての IP Phone のレポートを生成するには、各ドロップダウン リスト ボックスから次の設定を選択し、[Submit] ボタンをクリックします。

        [Product]:[All]

        [Feature]:[Call Pre-emption (for MLPP)]

        [List Features] ペインに、MLPP 機能をサポートするすべてのデバイスのリストが表示されます。 カラムの見出し([Product] または [Protocol])の隣にある上下の矢印キーをクリックして、リストをソートできます。


        インタラクションおよび制限事項

        この項では、MLPP のインタラクションおよび制限事項について説明します。

        インタラクション

        MLPP は、次の Cisco Unified Communications Manager 機能と通信します。

        • Cisco Extension Mobility:ユーザがエクステンション モビリティを使用してデバイスにログインした場合、MLPP サービス ドメインはユーザ デバイス プロファイルとの関連付けを維持します。 エクステンション モビリティでは、[MLPP通知(MLPP Indication)] 設定と [MLPPプリエンプション(MLPP Preemption)] 設定も適用されます。 デバイスまたはデバイス プロファイルが MLPP をサポートしていない場合、これらの設定は適用されません。

        • 即時転送:即時転送は、コールのタイプ(たとえば、優先コール)に関係なく、ボイスメール メールボックスへコールを転送します。 Alternate Party Diversion(コールの優先順位)がアクティブになっている場合は、無応答時転送(CFNA)も非アクティブになります。

        • Cisco Unified Communications Manager Assistant(Unified CM Assistant):MLPP は、次のように Unified CM Assistant と通信します。

          • Cisco Unified Communications Manager Assistant で MLPP 優先コールが処理される場合、Cisco Unified Communications Manager Assistant によりコール優先順位が保持されます。

          • Cisco Unified Communications Manager Assistant は、他のすべてのコールと同じように MLPP 優先コールをフィルタリングします。 コールの優先順位は、コールがフィルタリングされるかどうかには影響を与えません。

          • Cisco Unified Communications Manager Assistant はコールの優先順位を登録しないので、Assistant Console でコールの優先順位について追加のインジケータを送信することはありません。

        • Resource Reservation Protocol(RSVP):RSVP は最初から MLPP をサポートしています。 RSVP がアクティブな場合の MLPP の動作については、『Cisco Unified Communications Manager システム ガイド』に説明があります。

        • 補足サービス:MLPP は、複数ライン アピアランス、コール転送、自動転送、三者通話、コール ピックアップ、およびハント パイロットと通信します。各サービスとのインタラクションについて説明している MLPP 補足サービスおよび後続の項を参照してください。

        制限事項

        MLPP には、次の制限事項があります。

        • 共通ネットワーク ファシリティ プリエンプションがサポートされるのは、Cisco Unified Communications Manager が MGCP プロトコルを使用して制御し、MLPP プリエンプション対応として設定されたターゲット Voice over IP ゲートウェイ上の T1-CAS および T1-PRI(北米)インターフェイスに対してだけです。

        • User Access Channel がサポートされるのは、次の Cisco Unified IP Phone モデルに対してだけです。これらは、MLPP プリエンプション対応として設定されている必要があります。

          • Cisco Unified IP Phone 7960、7962、7965

          • Cisco Unified IP Phone 7940、7942、7945

        • IOS ゲートウェイは、Cisco Unified Communications Manager への SCCP インターフェイスをサポートします。 したがって、Cisco Unified Communications Manager でサポート対象の電話機モデルとして表示される BRI とアナログ電話機をサポートします。 MLPP 機能をサポートしているのは SCCP 電話機のみです。

        • トーンや呼び出し音など、MLPP 関連の通知を生成するのは MLPP 通知対応のデバイスだけです。 MLPP 通知対応ではないデバイスで優先コールが終了した場合、優先順位呼び出し音は再生されません。 MLPP 通知対応ではないデバイスから優先コールが発信された場合、優先順位呼び戻し音は再生されません。 差し替えられるコール(つまり、プリエンプションを開始したコールの相手側)に MLPP 通知対応ではないデバイスが含まれている場合、そのデバイスにプリエンプション トーンは再生されません。

        • 電話機の場合、MLPP 通知対応ではないデバイス(つまり、[MLPP通知(MLPP Indication)] が [オフ(Off)] に設定されている)でプリエンプションは実行できません。

          トランクの場合、MLPP 通知とプリエンプションは別々に機能します。

        • Cisco Unified Communications Manager は Look Ahead for Busy(LFB)オプションをサポートしていません。

        • クラスタ間トランク MLPP は、ダイヤルされた数値によって優先順位情報を送達します。 ドメイン情報は保存されないため、着信コールのトランクごとに設定する必要があります。

        • 729 Annex A をサポートしています。

        • さまざまなロケーション帯域幅のプリエンプション制限があります。

        • DRSN の場合、CDR は値 0、1、2、3、および 4 の優先レベルを表しており、DSN で使用されているように 0 はエクゼクティブ オーバーライドを示し、4 は標準を示します。 このように CDR は DRSN フォーマットを使用していません。

        • Cisco Unified Communications Manager は、優先順位の高いコールのビデオ帯域幅を調整するときに、下位優先レベルのコールをプリエンプション処理します。 プリエンプション処理する帯域幅が十分にない場合、Cisco Unified Communications Manager は、事前に予約されている下位ビデオ帯域幅を使用するようにエンドポイントに指示します。 Cisco Unified Communications Manager がビデオ コールをプリエンプション処理する場合、プリエンプション処理される側は、プリエンプション トーンを受信し、コールがクリアされます。

        • MLPP 対応デバイスは回線グループではサポートされません。 このため、シスコは次のガイドラインを推奨しています。

          • 回線グループ内では MLPP 対応デバイスを設定しないでください。 ただし、ルート グループはサポートしています。 トランク選択とハンティングの両方の方法がサポートされています。

          • 回線グループまたはルート グループで MLPP 対応デバイスが設定されている場合、プリエンプション イベント中にルート リストがデバイスにロックされていないと、差し替えられたコールはルート リストまたはハント リストの他のデバイスに再ルーティングされる可能性があります。また、どのデバイスもコールを受信できない場合にだけ、プリエンプション インジケータが返されることがあります。

          • ルート リストは、トランク選択および優先コールのハンティングのいずれかのアルゴリズムをサポートするように設定できます。 方法 1 では、Preemptive 検索を直接実行します。 方法 2 では、最初に一般的な検索を実行します。 この検索がうまく行かない場合は、Preemptive 検索を実行します。 方法 2 では、ルート リストのデバイス全体に 2 回繰り返す必要があります。

            方法 2 にルート リストが設定されている場合、回線グループを含む特定のシナリオでは、ルート リストはデバイス全体を 2 度繰り返して優先コールを検索することになります。

        • [MLPP通知(MLPP Indication)] を(エンタープライズ パラメータ、共通デバイス設定、またはデバイス レベルで)オンにすると、デバイスの [MLPP通知(MLPP Indication)] がオフ(無効)になっていない限り、デバイス上の回線では通常の呼び出し音設定の動作が無効になります。

        • 補足サービス:補足サービスに対する MLPP サポートでは、次の制限事項が指定されます。

          • 現在の MLPP 設計は、他グループ ピックアップではなく、基本のコール ピックアップ機能およびグループ コール ピックアップ機能だけに対応しています。 ダイレクト コール ピックアップ機能のサポートは、コール ピックアップの説明のとおりに機能します。

          • 着信 MLPP コールに対する不在転送(CFA)サポートでは、MAP ターゲットが設定されている場合、コールを常に着信側の MAP ターゲットに自動転送します。 設定が正しくない場合(つまり、MAP ターゲットが指定されていない場合)、コールは拒否され、発呼側ではリオーダー音が聞こえます。

          • 着信 MLPP コールに対する無応答時転送(CFNA)サポートでは、コールを CFNA ターゲットに 1 回自動転送します。 最初のホップの後、コールが無応答状態の場合、MAP ターゲットが設定されていれば、コールは元の着信側の MAP ターゲットに送信されます。 設定が正しくない場合(つまり、MAP ターゲットが指定されていない場合)、コールは拒否され、発呼側ではリオーダー音が聞こえます。

          • 着信 MLPP コールに対する話中転送(CFB)サポートでは、転送ホップに設定されている最大数までコールを自動転送します。 最大ホップ数に達した場合、MAP ターゲットが設定されていれば、コールは元の着信側の MAP ターゲットに送信されます。 設定が正しくない場合(つまり、MAP ターゲットが指定されていない場合)、コールは拒否され、発呼側ではリオーダー音が聞こえます。

          • ハント パイロットのサポートでは、ハント グループ アルゴリズムが最長アイドル時間、優先度順、またはラウンドロビンを指定している必要があります。 ビジー処理、応答なし処理、および未登録処理のハント グループ オプションが [次のメンバへ、ただし次のグループにはハントしない(Try next member, but do not go to next group)] に設定されていることを確認します。 プリエンプションが行われるのは、1 つのハント グループだけです。

        設定の詳細については、MLPP の設定を参照してください。

        MLPP のインストールおよびアクティブ化

        システム機能である MLPP は、Cisco Unified Communications Manager ソフトウェアに標準で備わっており、特別なインストールは必要ありません。

        MLPP の設定

        この項では、MLPP のエンタープライズ パラメータの設定について説明します。


        ヒント


        MLPP を設定する前に、この機能の設定タスクの概要を確認してください。


        関連タスク

        MLPP のエンタープライズ パラメータの設定

        Cisco Unified Communications Manager には、MLPP に適用される以下のエンタープライズ パラメータが用意されています。 MLPP サービスを使用可能にするには、指示に従って MLPP 関連のエンタープライズ パラメータを設定してください。

        • MLPP Domain Identifier:デフォルトはゼロ(0)です。 このパラメータは、ドメインを定義するために設定します。 MLPP サービスはドメインに適用されるため、Cisco Unified Communications Manager は、指定されたドメイン内の MLPP ユーザからのコールに属す接続とリソースだけに優先レベルのマークを付けます。 Cisco Unified Communications Manager は、同じドメイン内の MLPP ユーザからの優先順位の低いコールだけを差し替えることができます。


          (注)  


          このパラメータの変更を有効にするには、すべてのデバイスをリセットする必要があります。


        • MLPP Indication Status:デフォルトは、[MLPP Indication turned off] です。 このパラメータは、デバイスが MLPP 優先コールを示すために MLPP トーンと特別な表示を使用するかどうかを指定します。 エンタープライズで MLPP 通知を有効にするには、このパラメータを [MLPP Indication turned on] に設定します。


          (注)  


          このパラメータの変更を有効にするには、すべてのデバイスをリセットする必要があります。


        • MLPP Preemption Setting:デフォルトは、[No preemption allowed] です。 このパラメータは、優先順位の高いコールを接続するためにデバイスがプリエンプションおよびプリエンプション シグナル(プリエンプション トーンなど)を適用するかどうかを指定します。 エンタープライズで MLPP プリエンプションを有効にするには、このパラメータを [Forceful Preemption] に設定します。


          (注)  


          このパラメータの変更を有効にするには、すべてのデバイスをリセットする必要があります。


        • Precedence Alternate Party Timeout:デフォルトは 30 秒です。 優先コールで、着信側が Alternate Party Diversion に加入している場合、このタイマーは、着信側がプリエンプションに受信応答しない場合や優先コールに応答しない場合に Cisco Unified Communications Manager がコールを代替パーティに転送するまでの秒数を示します。
        • Use Standard VM Handling For Precedence Calls:デフォルトは [False] です。 このパラメータは、優先コールがボイスメール システムに自動転送されるかどうかを指定します。 このパラメータが [False] に設定されている場合、優先コールはボイスメール システムに転送されません。 このパラメータが [True] に設定されている場合、優先コールはボイスメール システムに転送されます。 MLPP では、ボイスメール システムではなくユーザが常に優先コールに応答する必要があるので、このパラメータを [False] に設定することをお勧めします。

        エンタープライズ パラメータの詳細については、『Cisco Unified Communications Manager Bulk Administration ガイド』のMLPP の設定の章を参照してください。

        Destination Code Control

        Destination Code Control(DCC)は、同じ宛先へのフラッシュ、フラッシュ オーバーライドおよびエクゼクティブ オーバーライド優先レベル コール(フラッシュ以上の優先レベルのコール)は無制限に許可しつつ、特定の宛先に許可される下位優先レベルのコールの数を制限します。

        DCC が有効なルート パターンは、フラッシュ以上の優先レベルの各コールの処理を許可しますが、宛先の管理者により設定されるブロック割合に基づいて許可または拒否することで、下位優先レベルのコールの割合を規制します。 DCC が有効なルート パターンは、管理者が設定するブロック コール率に基づいて、即時、プライオリティおよびルーチン(フラッシュより低い優先レベル)コールを制限します。 緊急時では、DCC により、管理者は、特定の宛先へのコール トラフィックの量を制御できます。 DCC が有効なルート パターンを介した低い優先順位の発信コールの数は、常に、そのルート パターンで設定された最大許可コール数以下になります。

        ブロック コール率は、Cisco Unified Communications Manager の [ルートパターンの設定(Route Pattern Configuration)] ウィンドウで設定できます。

        [ルートパターンの設定(Route Pattern Configuration)] ウィンドウの [ブロックコール率の適用(Apply Call Blocking Percentage)] チェックボックスにアクセスするには、[コールルーティング(Call Routing)] > [ルートハント(Route Hunt)] > [ルートパターン(Route Pattern)] を選択します。

        Cisco Unified Communications Manager クラスタの各ノードは、ノードを介してブロックされるコールの数を別々に追跡します。 次のノードは、他のノードでの追跡と同期化せずに、ノードを介してルートされるコールの数を別々に追跡します。

        [ブロックコール率の適用(Apply Call Blocking Percentage)] を選択し、ブロック コール率を特定の値に設定して、DCC を有効にした後、ブロック コール率の値を変更せずに、[ゲートウェイ/ルートリスト(Gateway/Route List)] や [ルートクラス(Route Class)]、または [ルートパターン(Route Pattern)] ウィンドウのその他のフィールドを変更した場合、DCC カウンタはリセットされません。ただし、変更前にルート パターンを介して試行されたコール数に基づいたカウントは継続します。 DCC カウンタをリセットするには、[ブロックコール率の適用(Apply Call Blocking Percentage)] フィールドを変更する必要があります。


        (注)  


        DCC 機能を有効にする場合、[ルートパターン(Route Pattern)] ウィンドウの MLPP レベルを [フラッシュ(Flash)]、[フラッシュオーバーライド(Flash Override)] または [エクゼクティブオーバーライド(Executive Override)] レベルに設定できません。 これらの MLPP レベルは、トランスレーション パターンで設定する必要があります。


        AXL

        シン AXL レイヤを介してルート パターンで DCC 機能を設定できます。

        設定要件

        DCC を有効にするには、次のフィールドを更新する必要があります。

        • [ブロックコール率の適用(Apply Call Blocking Percentage)]:このチェックボックスをオンにして、DCC 機能を有効にします。 DCC が有効になると、宛先に発信されるフラッシュ以上の優先レベルのコールを除くすべてのコールがフィルタリングされ、宛先で設定されたブロック コール率クォータに基づいて許可または拒否されます。 フラッシュ以上の優先レベルのコールは常に許可されます。 DCC は、デフォルトでは無効になっています。

        • ブロックコール率(%):この宛先でブロックされるコールの割合を数値で入力します。 この値は、ルート パターンでブロックされる、この宛先に発信される下位優先レベルのコールの割合を指定します。 この割合は、下位優先レベルのコールだけを制限します。この宛先に発信される、フラッシュ以上の優先レベルのコールは常に許可されます。


        (注)  


        Cisco Unified Communications Manager では、この宛先に設定されているブロック コール率に基づいて、このルート パターンを介して許可される優先順位の低いコールの最大数を計算します。



        (注)  


        ブロックコール率(%)のフィールドは、[ブロックコール率の適用(Apply Call Blocking Percentage)] チェックボックスがオンの場合だけ有効になります。


        BAT の変更

        BAT の [インポート/エクスポート(Import/Export)] メニューを介して DCC の詳細をエクスポートできます。

        BAT を介して DCC の詳細をエクスポートするには、[一括管理(Bulk Administration)] > [インポート/エクスポート(Import/Export)] > [エクスポート(Export)] を選択します。 エクスポートの [ルートパターン(Route Pattern)] エンティティを選択します。 DCC の詳細は、[コールルーティングデータ(Call Routing Data)] にあります。


        (注)  


        [インポート/エクスポート(Import/Export)] の詳細については、『Cisco Unified Communications Manager Bulk Administration ガイド』を参照してください。