MLPP の概要
Multilevel Precedence and Preemption(MLPP)サービスを使用すると、優先コールをかけることができます。適切に検証されたユーザは、優先順位の低いコールよりも優先順位の高いコールを優先させることができます。認証されたユーザは、宛先ステーションへ、または完全にサブスクライブされた TDM トランクを介して、コールをプリエンプション処理することができます。この機能により、国家の非常事態やネットワークの機能低下など、ネットワークに負荷がかかっている場合に、優先順位の高いユーザが重要な組織や担当者への通信を確実に行うことができます。
次のトピックで、MLPP サービスについて説明します。
•
「MLPP の用語」
•
「優先順位」
•
「エクゼクティブ オーバーライド優先レベル」
•
「プリエンプション」
•
「ドメイン」
•
「ロケーション ベースの MLPP」
•
「クラスタ間トランク経由の MLPP」
•
「MLPP 優先パターン」
•
「MLPP 表示対応」
•
「優先コールの設定」
•
「Alternate Party Diversion」
•
「MLPP プリエンプション対応」
•
「プリエンプションの詳細」
•
「MLPP アナウンス」
•
「優先順位パターン用の MLPP 番号計画アクセス制御」
•
「MLPP トランク選択」
•
「MLPP 階層設定」
•
「サービス パラメータの特別なトレース設定」
•
「優先コール用の CDR の録音」
•
「回線機能のインタラクション」
•
「コール保存」
•
「自動代替ルーティング」
•
「MGCP と PRI プロトコル」
•
「セキュアなエンドポイントとセキュアな通信」
MLPP の用語
MLPP サービスでは次の用語を使用します。
•
コール:2 人以上のユーザ間または 2 つ以上のネットワーク エンティティ間の音声、ビデオ、またはデータの接続。これは、番号をダイヤルするか、または定義済みのダイヤル プランに従って宛先にルーティングすることで実現されます。
•
優先順位:コールに関連付けられた優先レベル。
•
プリエンプション:優先順位の低い既存のコールを終了させ、優先順位の高いコールにターゲット デバイスを使用させるプロセス。
•
優先コール:最も低い優先レベルよりも高い優先レベルを持つコール。
•
MLPP コール:優先レベルが確立された、設定中(つまり、アラート前)のコールまたは設定済みのコール。
•
アクティブなコール:接続が確立され、発信側と着信側がアクティブになったコール。
•
MLPP ドメイン ID:MLPP 加入者に関連付けられたデバイスとリソースの集合を指定します。特定のドメインに属す MLPP 加入者が、同じドメインに属す別の MLPP 加入者に優先コールをかけると、MLPP サービスは、着信側の MLPP 加入者の既存のコールを優先順位の高いコールに差し替えます。MLPP サービスは、異なるドメイン間では使用できません。
•
MLPP 表示対応のデバイス:Cisco Unified CallManager で、デバイスと Cisco Unified CallManager によってデバイス制御プロトコルで優先順位とプリエンプションのシグナリング手順がサポートされ、Cisco Unified CallManager システムでそのように設定されているデバイス。
•
MLPP プリエンプション対応のデバイス:Cisco Unified CallManager で、デバイスと Cisco Unified CallManager によってデバイス制御プロトコルでプリエンプションのシグナリング手順がサポートされ、Cisco Unified CallManager システムでそのように設定されているデバイス。Cisco Unified CallManager はこのインターフェイスでプリエンプションを開始できます。
優先順位
優先順位は、コールに関連付けられた優先レベルを示します。優先順位の割り当てはその場限りのものであり、ユーザは自分がかけようとしているコールに優先レベルを適用するかしないかを選択します。MLPP の優先順位は、コール アドミッション制御または拡張型緊急通報システム(E911)とは関係していません。ユーザは Cisco Unified CallManager の管理ページの専用ダイヤル パターンによって MLPP 要求を開始できます。発信側(デバイスや回線など)に関連付けられたコーリング サーチ スペース(CSS)の設定によって、発信側が優先パターンをダイヤルして優先コールを発信できるかどうかが制御されます。
Defense Switched Network(DSN)および Defense Red Switched Network(DRSN)は、初期 MLPP 配置用のターゲット システムを示します。通常は、優先レベルをコールに割り当てるメカニズムを適用しますが、Cisco Unified CallManager の管理ページでは、優先ダイヤル パターンやそのパターンへのアクセスを許可または制限するコーリング サーチ スペースを定義することによって、任意のダイヤル プランに優先レベルを割り当てることができます。DSN では、ストリング プレフィックス NP を使用して優先コールを要求できるようにダイヤル プランが定義されます。NP の P は優先レベルの要求を示し、N は事前設定された MLPP へのアクセス番号を示します。優先順位は次のとおりです。
•
エクゼクティブ オーバーライド
•
フラッシュ オーバーライド
•
フラッシュ
•
即時
•
プライオリティ
•
標準
優先順位を呼び出さなければ、システムは通常のコール処理とコール転送を使用してコールを処理します。
デフォルトの割り当てまたはエクステンション モビリティでユーザ プロファイルが電話機に割り当てられている場合、電話機は、ユーザに関連付けられた CSS を含め、割り当てられたユーザの設定を継承します。ただし、電話機の CSS はユーザ プロファイルを上書きできます。Cisco Unified CallManager は、パターンが一致した場合に、ダイヤルされたパターンに関連する優先レベルをコールに割り当てます。システムは、割り当てられた優先レベルで、コール要求を優先コールとして設定します。
ある宛先に対して優先コールが発信されると、Cisco Unified CallManager は、優先コールの発信元または宛先のいずれかが MLPP 表示対応である場合に、発信元と宛先の両方に優先順位のインジケータを送信します。発信元の場合、このインジケータは、優先順位の呼び戻し音と、デバイスで表示がサポートされている場合はコールの優先レベルまたはドメインの表示で示されます。宛先の場合、このインジケータは、優先順位呼び出し音と、デバイスで表示がサポートされている場合はコールの優先レベルまたはドメインの表示で示されます。
エクゼクティブ オーバーライド優先レベル
最高の優先レベルとしてエクゼクティブ オーバーライド優先レベルが指定されています。エクゼクティブ オーバーライド優先レベルが優先順位の低いコールを差し替えるときに、エクゼクティブ オーバーライド コールはその優先レベルをフラッシュ オーバーライド(次に高いレベル)に変更するため、後続のエクゼクティブ オーバーライド コールは最初の優先コールを差し替えることができます。
エクゼクティブ オーバーライド優先コールの差し替えには、Executive Override Call Preemptable サービス パラメータを[True]に設定する必要があります。このサービス パラメータを[False]に設定すると、エクゼクティブ オーバーライド優先コールはその優先レベルを保持するため、差し替えることができません。
図14-1 に、2 つのエクゼクティブ オーバーライド優先コールの例を示します。一方は差し替えが可能で、もう一方は差し替えができません。
図14-1 エクゼクティブ オーバーライド優先コールの例
この例では、Cisco Unified CallManager クラスタ 1 の Executive Override Call Preemptable サービス パラメータには[False]が指定されていますが、Cisco Unified CallManager クラスタ 2 では、Executive Override Call Preemptable サービス パラメータに[True]が指定されています。
ONA は T1 PRI 4ESS トランクを通して、クラスタ 1 からクラスタ 2 の DNA へのエクゼクティブ オーバーライド優先コールを開始します。DNA が応答し、コールが接続されます。
クラスタ 1 で、ONB がエクゼクティブ オーバーライド優先コールを使用して ONA にコールしようとすると、クラスタ 1 ではエクゼクティブ オーバーライド コールを差し替えることができないため、ONB は BPA(Blocked Precedence Announcement)を受信します。ONB がエクゼクティブ オーバーライド優先コールを使用して DNA にコールしようとすると、クラスタ 2 ではエクゼクティブ オーバーライド コールを差し替えることができるため、ONA と DNA の間のコールは差し替えられます。同様に、エクゼクティブ オーバーライド優先コールを使用して DNB が DNA をコールすると、後続のエクゼクティブ オーバーライド優先コールは ONA と DNA の間のコールを差し替えます。
エクゼクティブ オーバーライド優先コールの設定
図14-2 に、エクゼクティブ オーバーライド優先コールが行われた場合のイベントの例を示します。
図14-2 エクゼクティブ オーバーライド優先コールの設定
この例では、電話機 1000 がオフフックになり、9*1001(ルート パターン 9*XXXX 設定にはエクゼクティブ オーバーライドが指定されている)をダイヤルします。
発信元では、この優先コールが成功すると、Cisco Unified CallManager はユーザへの呼び戻し音を再生する信号を Cisco Unified IP Phone に送ります。Cisco Unified IP Phone 1000 が MLPP 表示対応の場合、優先順位呼び戻し音が再生されます。これ以外の場合は、通常の呼び戻し音が再生されます。
優先コールが接続できない場合、Cisco Unified IP Phone 1000 が MLPP 表示対応であれば、Blocked Precedence Announcement(BPA)が再生されます。これ以外の場合は、通常のリオーダー音が再生されます。
宛先では、エクゼクティブ オーバーライド優先コールが Cisco Unified IP Phone 1001 に正しく提供されると、デバイスで可聴呼び出し音を生成する信号が Cisco Unified CallManager によって宛先に送信されます。Cisco Unified IP Phone 1001 が MLPP 表示対応であれば、優先順位呼び出しが再生されます。これ以外の場合は、通常の呼び出し音が再生されます。
また、電話機 1001 が MLPP 表示対応である場合は、Cisco Unified IP Phone 1001 に優先情報(フラッシュ オーバーライド優先コール アイコンなど)が表示されます。これ以外の場合は、優先情報は表示されません。
PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コール
図14-3 に、PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コールの例を示します。
図14-3 PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コール
Cisco Unified CallManager では、PRI 4ESS インターフェイス間のエクゼクティブ オーバーライド優先コールを処理する際、PRI 4ESS UUIE を介した優先レベル以外は、他の優先コールの処理に使用する方法と同じ方法を使用します。
UUIE を介した優先情報が渡されるのは、[サービスパラメータ設定(Service Parameter Configuration)]ウィンドウ上の[User-to-User IE Status]が[True]になっており、[ゲートウェイの設定(Gateway Configuration)]ウィンドウの[UUIEを介した優先レベルの通知(Passing Precedence Level Through UUIE)]が選択されている場合に限られます。
DRSN への PRI 4ES UUIE ベースの MLPP インターフェイス
以前のリリースの Cisco Unified CallManager は、Defense Switched Network(DSN)スイッチに接続するために、ANSI.619a 仕様に従って開発された PRI インターフェイス用の MLPP を提供しました。Defense Red Switch Network(DRSN)スイッチは、ANSI T1.619a ベースの MLPP をサポートしていませんが、UUIE を使用することで PRI 4ESS インターフェイス上の MLPP をサポートしています。Cisco Unified CallManager は、PRI 4ESS UUIE フィールド経由で MLPP 情報を渡すことができるようになりました。
プリエンプション
プリエンプション プロセスは、優先順位の高いコールがデバイスを使用できるように、現在ターゲット デバイスを使用している優先順位の低いコールを終了させます。プリエンプションには、プリエンプション処理されるユーザへの通知とそれに対する受信応答、およびプリエンプションの直後とコールの終了前の共有リソースの予約が含まれます。プリエンプションは、どのメソッドが起動するかに応じて、次のいずれかの形式をとります。
•
ユーザ アクセス チャネル プリエンプション:このタイプのプリエンプションは、電話機およびその他のエンドユーザ デバイスに適用されます。また、着信側のユーザ アクセス チャネルを差し替える必要がある場合に、着信側と接続先の両方がプリエンプション通知を受信し、既存の MLPP コールがすぐにクリアされます。着信側は、優先順位の高いコールが実行される前に、プリエンプションに受信応答する必要があります。その後、着信側には新規 MLPP コールが提供されます。着信側がプリエンプションに受信応答しない場合、優先順位の高いコールは 30 秒後に実行されます。
•
共通ネットワーク ファシリティ プリエンプション:このタイプのプリエンプションは、トランクに適用されます。このタイプのプリエンプションは、ネットワーク リソースがコールで混雑しており、このうちの一部のコールの優先順位が、発信側が要求しているコールよりも低くなっていることを意味します。1 つまたは複数の優先順位の低いコールが、優先順位の高いコールに差し替えられます。
(注) 既存のコールを差し替えるためにコールが使用するすべてのデバイスでプリエンプションが有効になっていることを確認してください。発信側と着信側のデバイス(電話機)でプリエンプションが有効になっているだけでは不十分なので、コールに使用されるゲートウェイでもプリエンプションが有効になっていることを確認してください。
ドメイン
発信ユーザによる MLPP ドメインへの加入によって、コールのドメインとその接続が決まります。あるドメイン内の優先順位の高いコールだけが、同じドメイン内のコールが使用している接続を差し替えることができます。
管理者は、ゼロ以上の 16 進数として Cisco Unified CallManager の管理ページにドメインを入力します。
追加情報
「関連項目」を参照してください。
ロケーション ベースの MLPP
Cisco Unified CallManager は、Skinny Client Control Protocol の電話機と TDM(PRI/CAS)トランクでの MLPP をサポートしています。Cisco Unified CallManager は、Wide Area Network(WAN; ワイドエリア ネットワーク)リンク上の MLPP もサポートしています。ロケーション ベースの Call Admission Control(CAC; コール アドミッション制御)は、Cisco Unified CallManager の WAN リンクの帯域幅を管理します。優先順位の高いコールを接続する必要がある場合、拡張されたロケーションでは、コールの優先レベル、および低い優先レベルのコールの差し替えが考慮されます。
ロケーションの拡張とは、優先コールが着信し、そのコールを宛先のロケーションに接続する十分な帯域幅が見つからない場合に、Cisco Unified CallManager が優先レベルの最も低い 1 つ以上のコールを探して、コールを差し替え、優先順位の高いコールに利用できる帯域幅を確保することです。差し替え処理を行っても帯域幅の要件を満たすことができないと、新しいコールは失敗します。
追加情報
「関連項目」を参照してください。
クラスタ間トランク経由の MLPP
Cisco Unified CallManager は、クラスタ間トランク経由の MLPP 優先順位とプリエンプションをサポートしています。ダイヤルした数値によって優先レベルを通知します。ロケーション コール アドミッション制御メカニズムは、プリエンプションを制御します。アナウンスと MLPP 原因コードも、クラスタ間トランク経由で使用できます。
MLPP 優先パターン
MLPP 優先パターンを設定するには、Cisco Unified CallManager の管理ページの[変換パターンの設定(Translation Pattern Configuration)]ウィンドウにアクセスします。このウィンドウでは、次の MLPP 優先パターンを使用できます。
•
エクゼクティブ オーバーライド(最高)
•
フラッシュ オーバーライド
•
フラッシュ
•
即時
•
プライオリティ
•
標準(最低)
•
デフォルト(優先レベルが変更されないことを意味します)
詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「変換パターンの設定」を参照してください。
MLPP 表示対応
MLPP 表示対応のデバイスには次の特徴があります。
•
MLPP 表示対応のデバイスは、プリエンプション トーンを再生できます。
•
MLPP 表示対応のデバイスは、アナウンス サーバが生成する MLPP プリエンプション アナウンスを受信できます。
•
MLPP 表示対応のデバイスは、プリエンプションを受信できます。
デバイスを設定して MLPP 表示を有効にするには、各デバイスの設定ウィンドウを使用します。各デバイスの[MLPP表示(MLPP Indication)]フィールドで、値を[On]に設定します。
デバイスに対する MLPP 表示の設定の詳細については、次のトピックを参照してください。
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「デバイス プールの設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ゲートウェイの設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「Cisco Unified IP Phone の設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「デバイス プロファイルの設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「デフォルト デバイス プロファイルの設定」
優先コールの設定
優先コールの設定では、次の一連のイベントが発生します。
1.
ユーザが電話機をオフフックにして優先コールをダイヤルします。コール パターンは NP-XXX を指定しています。ここで、N は優先アクセス番号を示し、P はコールの優先レベルを示します。
2.
発信側は、コールの処理中に特別な優先順位の呼び戻し音と優先順位表示を受信します。
3.
着信側は、優先コールを示す特別な優先順位呼び出し音と優先順位表示を受信します。
例
ユーザ 1000 がユーザ 1001 に優先コールをかけます。そのために、ユーザ 1000 は 90-1001 などの優先コール パターンをダイヤルします。
コールが処理されると、発信側の Cisco Unified IP Phone が優先順位呼び戻し音と優先順位表示を受信します。着信側が優先コールに受信応答すると、着信側の Cisco Unified IP Phone は、優先順位呼び出し音(特別な呼び出し音)と優先順位表示を受信します。
クラスタ間トランクの間での優先コールの設定
図14-4 に、クラスタ間トランクの間での優先コールに使用できる設定例を示します。クラスタ間トランクの間には、優先情報要素のサポートは存在しないため、追加ディジットを転送することで優先情報を送信します。優先情報の送信を実行するには、両方のクラスタにダイヤル プランを適切に設定する必要があります。
図14-4 クラスタ間トランクの間での優先コールの設定例
この例では、1000 は 92-2000 をダイヤルします。これは両方のクラスタの適切な優先パターンに一致しており、優先コールを設定します。
Alternate Party Diversion
Alternate Party Diversion(APD)は、特別なタイプのコール転送から構成されます。ユーザが APD に設定されている場合は、通話中または応答のない電話番号(DN)に優先コールがかけられたときに APD が実行されます。
MLPP APD は優先コールだけに適用されます。MLPP APD コールは、優先コールの DN Call Forward No Answer 設定を無効にします。
通常、優先コールは、Use Standard VM Handling For Precedence Calls エンタープライズ パラメータの値で制御されるので、ボイスメール システムには転送されません。詳細については、「MLPP のエンタープライズ パラメータの設定」を参照してください。
APD を設定するために、管理者は、MLPP 優先コールのターゲットとなる電話番号の[電話番号の設定(Directory Number Configuration)]ウィンドウで[MLPP代替パーティの設定(MLPP Alternate Party Settings)]を設定します。詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「Cisco Unified IP Phone の設定」を参照してください。
例
図14-5 に、着信側が優先コールを受信し、Alternate Party Diversion の発信先が設定されている場合の Alternate Party Diversion を示します。
図14-5 Alternate Party Diversion の例
この例では、発信側がユーザ 1000 に優先コールをかけます。着信側の 1000 には Call Forward Busy(CFB)用に 2000 が設定され、Call Forward Alternate Party(CFAP)用に 1001 が設定されています。この図には、この例の他のすべてのユーザの CFB 設定と CFAP 設定が示されています。
1000 が優先コールを受信したときに通話中である場合、コールはユーザ 2000 へ送信されます。ユーザ 2000 も通話中である場合、コールはユーザ 3000 へ送信されます。ユーザ 2000 もユーザ 3000 もコールに応答しない場合、コールはユーザ 1001 へ送信されます。つまり、コールは、元の着信側に関連する Call Forward Busy ユーザに対して指定された代替パーティではなく、元の着信側に対して指定された代替パーティへ送信されます。
同様に、ユーザ 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 CallManager アドミニストレーション ガイド 』の「デバイス プールの設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ゲートウェイの設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「Cisco Unified IP Phone の設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「デバイス プロファイルの設定」
•
『 Cisco Unified CallManager アドミニストレーション ガイド 』の「デフォルト デバイス プロファイルの設定」
プリエンプションの詳細
次の種類のプリエンプションが存在します。
•
ユーザ アクセス プリエンプション
•
共通ネットワーク ファシリティ プリエンプション
•
ロケーションベースのプリエンプション
ユーザ アクセス プリエンプション
低いレベルの優先コールがすでにアクティブであるユーザに優先コールを行う場合、ユーザアクセス プリエンプションが実行されます。いずれのコールも同じ MLPP ドメインに存在します。このタイプのプリエンプションは、Cisco Unified CallManager MLPP システムで Cisco Skinny Client Control Protocol が制御する MLPP 表示対応の電話機に対して使用できます。プリエンプションは、優先コール要求が検証された場合や、要求されたコールの優先順位が宛先の MLPP プリエンプション対応の電話機で接続されている既存のコールの優先順位よりも高い場合に実行されます。コール処理は、プリエンプション トーンを使用して接続先にプリエンプションを通知し、アクティブなコールをリリースします。着信側は電話を切ることによってプリエンプションに応答し、新規 MLPP コールを取得します。
ユーザ アクセス プリエンプションで実行される一連のステップを理解するために、次の例を参照してください。
例
図14-6 に、ユーザ アクセス プリエンプションの例を示します。
図14-6 ユーザ アクセス プリエンプションの例
このユーザ アクセス プリエンプションの例では、次の一連のイベントが発生します。
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 CallManager のデバイス制御プロトコルではプリエンプションがサポートされていません。管理者は、Cisco Unified CallManager の管理ページが手順をサポートしている場合でも、電話機でプリエンプション手順を無効にできます。
以前から、ユーザ アクセス デバイス(電話機)では、複数の同時コールを処理するメカニズムが制限されているか、まったくありませんでした。コール待機機能でも、多数の電話機および関連するスイッチには、ユーザが同じ回線で複数のコールを同時に管理できるようなメカニズムはありません。
Cisco Unified CallManager の管理ページは、コール待機機能を効果的に強化し、Cisco Unified IP Phone(794X および 796X シリーズ)のユーザにこの機能を提供しています。これらの Cisco Unified IP Phone には、ユーザが Cisco Unified CallManager システムとインターフェイスする際に複数の同時コールを適切に制御するためのユーザ インターフェイスが含まれています。この拡張機能を使用すると、ユーザがすでに他のコールを管理している場合でも、これらのタイプの電話機に送信されたすべての優先コールにコール待機機能を適用できます。ユーザが優先コールを受信すると、宛先の電話機のユーザは、優先順位の低いコールを単にリリースするだけでなく、既存のコールをどう処理するかを決定できます。これらのデバイスのユーザに対して、Cisco Unified CallManager 管理者は、Cisco Unified CallManager でこの機能を利用するためデバイスを非 MLPP プリエンプション対応として設定できます。
共通ネットワーク ファシリティ プリエンプション
共通ネットワーク ファシリティ プリエンプションは、MLPP システムでトランクなどのネットワーク リソースに適用されます。共通ネットワーク ファシリティでプリエンプションが行われると、既存のコールのユーザすべてがプリエンプションの通知を受信し、既存の接続がすぐに切断されます。新規コールは、新しい着信側への特別な通知なしで、プリエンプション処理されるファシリティを使用して通常どおり設定されます。ターゲット MGCP ゲートウェイ プラットフォーム上の PRI トランクと T1-CAS トランクは、Cisco Unified CallManager でこのタイプのプリエンプションをサポートします。
プリエンプションは、優先コール要求が検証された場合や、要求されたコールの優先順位が宛先の MLPP プリエンプション対応のトランクを介した既存のコールの優先順位よりも高く、トランクが完全に使用中である(つまり、コールをそれ以上処理できない)場合に実行されます。コール処理は、優先順位の低いコールを特定し、接続されたユーザに PRI トランク インターフェイスのプリエンプションを通知し、後続の使用のためにチャネルを予約し、選択された優先順位の低いコールを切断します。システムは予約されたチャネルを使用して、プリエンプションを起動した優先コール用にゲートウェイを介して接続を確立します。
共通ネットワーク ファシリティ プリエンプションで実行される一連のステップについては、次の例を参照してください。
例 1
図14-7 に、共通ネットワーク ファシリティ プリエンプションの例を示します。
図14-7 共通ネットワーク ファシリティ プリエンプションの例
この共通ネットワーク ファシリティ プリエンプションの例では、次の一連のイベントが発生します。
1.
ユーザ 1000 がユーザ 2000 に優先レベルがフラッシュ オーバーライドの優先コールをかけ、ユーザ 2000 がそれに応答します。この例では、ユーザ 1000 が優先コールをかけるために 90-2000 をダイヤルします。優先レベルがフラッシュ オーバーライドのフラッシュ コールはアクティブを指定します。
コールは、2 つのゲートウェイが完全にサブスクライブされた TDM を定義する共通ネットワーク ファシリティを使用します。
2.
ユーザ 1001 は次に、9*-2001 をダイヤルしてユーザ 2001 に優先順位の高い(エクゼクティブ オーバーライド)コールをかけます(フラッシュ コールがゲートウェイ A 上で最も優先順位の低いコールであることと、ユーザ 1000 とユーザ 1001 が同じ MLPP ドメイン内にあることを想定しています)。
ゲートウェイ A でプリエンプションが実行され、ゲートウェイ A が再利用のためプリエンプション処理されます。このインターフェイスではプリエンプションが実行されるので、このデバイスでプリエンプションが有効であることを確認する必要があります。ゲートウェイ B も再利用のためプリエンプション処理されますが、このインターフェイスではプリエンプションは実行されないので、このデバイスでプリエンプションを有効にする必要はありません。
ユーザ 1000 とユーザ 2000 の両方がプリエンプション トーンを受信します。どちらのデバイスも再利用のためのプリエンプション処理はされず、これらのインターフェイスではプリエンプションは実行されないので、これらのデバイスでプリエンプションを有効にする必要はありません。
この例では、ほとんどすべてのイベントが即時に発生します。共通ネットワーク ファシリティ プリエンプションを実行するために、ユーザが電話を切る必要はありません。
例 2
図14-8 に、リトライ タイマー Trr のある共通ネットワーク ファシリティ プリエンプションの例を示します。リトライ タイマー Trr は、あるチャネルでプリエンプションが成功しなかった場合に別のチャネルでプリエンプションを再試行するメカニズムを提供します。このタイマーは、TDM トランクだけに適用されます。
図14-8 リトライ タイマー Trr のある共通ネットワーク ファシリティ プリエンプション
このリトライ タイマー Trr のある共通ネットワーク ファシリティ プリエンプションの例では、次の一連のイベントが発生します。
1.
優先順位がフラッシュ オーバーライドの着信コールが PRI トランク デバイスに到着します。
着信コールによってチャネル 3 のプリエンプションが起動しますが、リトライ タイマー Trr で指定された時間内に応答がありません。
2.
リトライ タイマー Trr が時間切れになります。
チャネル 3 でプリエンプションが実行されます。
3.
このプリエンプションによって応答が行われ、チャネル 1 で優先コールが発信されます。
ロケーションベースのプリエンプション
次の例では、ロケーションベースのプリエンプションについて説明します。
例 1
次の例では、別のデバイスで新しいコールとロケーション優先コールが実行されます。この種類のロケーションベースのプリエンプションの例については、図14-9 を参照してください。
図14-9 別のデバイスにおけるロケーションベースのプリエンプション
この例では、ロケーションベースのプリエンプションのシナリオについて説明します。この例には、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
次の例では、同一のデバイスで新しいコールとロケーション優先コールが実行されます。この種類のロケーションベースのプリエンプションの例については、図14-10 を参照してください。
図14-10 同一デバイスでのロケーションベースのプリエンプション
この例では、ロケーションベースのプリエンプションのシナリオについて説明します。この例には、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 です。
Unauthorized Precedence Announcement
ユーザは、自分の回線に許可された最高の優先レベルよりも高い優先レベルのコールをかけようとすると、Unauthorized Precedence Announcement を受信します。ユーザは、自分に権限のない発信パターンを使用して優先コールをダイヤルしたときに、Unauthorized Precedence Announcement を受信します。
Cisco Unified CallManager は、パターンと一致してコールをブロックする理由が示されたコールの試行をブロックするように特定のパターンまたはパーティションが設定されている場合だけ、Precedence Level Exceeded の条件を認識します。
許可された発信パターンを割り当てるには、Cisco Unified CallManager の管理ページの[ルートパターンの設定(Route Pattern Configuration)]ウィンドウまたは[ハントパイロットの設定(Hunt Pilot Configuration)]ウィンドウと[変換パターンの設定(Translation Pattern Configuration)]ウィンドウを使用します。MLPP Precedence Level Exceeded の条件を設定するには、Cisco Unified CallManager の管理ページで、[ルートパターンの設定(Route Pattern Configuration)]ウィンドウまたは[ハントパイロットの設定(Hunt Pilot Configuration)]ウィンドウと[変換パターンの設定(Translation Pattern Configuration)]ウィンドウの[ルートオプション(Route Option)]フィールドを使用して[このパターンをブロック(Block this pattern)]オプションを選択します。ドロップダウン リスト ボックスで、[Precedence Level Exceeded]を選択します。詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「ルート パターンの設定」と「変換パターンの設定」を参照してください。
例
図14-11 に、Unauthorized Precedence Announcement を受信するユーザの例を示します。
図14-11 Unauthorized Precedence Announcement の例
この例では、ユーザ 1002 が優先コールを開始するために 90 をダイヤルします。9 は優先順位アクセス番号を示し、0 はユーザが使おうとしている優先レベルを示します。このユーザはフラッシュ オーバーライド優先コール(優先レベル 0 のコール)を許可されていないので、ユーザは Unauthorized Precedence Announcement を受信します。
Blocked Precedence Announcement
優先コールの宛先がオフフックである場合や、宛先が同等かそれ以上の優先順位の優先コールで通話中で、コール待機機能もコール転送機能もなく、Alternate Party Diversion(APD)の発信先も指定されていない場合、あるいは共通ネットワーク リソースがない場合、ユーザは Blocked Precedence Announcement を受信します。
例
図14-12 に、Blocked Precedence Announcement の例を示します。
図14-12 Blocked Precedence Announcement の例
この例では、ユーザ 1000 が 90-1001 をダイヤルしてユーザ 1001 に優先コールをかけます。ユーザ 1001 は、オフフックまたは同等以上の優先レベルの優先コールで通話中であり、コール待機機能もコール転送機能もなく、Alternate Party Diversion の発信先も指定されていないため、ユーザ 1000 は Blocked Precedence Announcement を受信します。
Busy Station Not Equipped for Preemption
ユーザは、ダイヤルした番号がプリエンプション対応ではない場合に、このアナウンスを受信します。つまり、ダイヤルした番号が通話中で、コール待機機能やコール転送機能がなく、Alternate Party Diversion の発信先も指定されていない場合です。
クラスタ間トランクを超えたアナウンス
図14-13 に、クラスタ間トランク上にストリームされる MLPP アナウンスのインスタンスを示します。
図14-13 クラスタ間トランク上の MLPP アナウンスの例
この例では、クラスタ間トランクが接続する 2 つのクラスタ上に電話機 1000 と 2000 が存在します。ユーザ 2000 には、コール待機やコール転送などの機能は設定されていません。
次の一連のイベントが順に発生します。
1.
ユーザ 2000 は、電話機をオフフックしてダイヤルを開始します(ユーザ 2000 のステータスは発信側ビジーとプリエンプション非対応が指定されています)。
2.
ユーザ 1000 はクラスタ間トランク経由でユーザ 2000 に優先コールをダイヤルします。ユーザ 2000 はビジーであり、プリエンプション対応ではないため、コールは拒否されます。
3.
ユーザ 1000 が優先コールを発信したため、コールは優先処理を受信し、リモート クラスタ上のアナウンス サーバは適切な Blocked Precedence Announcement(BPA)をスイッチ名とクラスタのロケーションとともにユーザ 1000 に送信します。
優先順位パターン用の MLPP 番号計画アクセス制御
MLPP は、ユーザに対して定義されたコーリング サーチ スペースとパーティションを使用して MLPP コールを認証および検証し、優先順位パターンにアクセス制御を提供します。
ユーザの最高優先順位は、ユーザ設定時に設定されます。MLPP 機能を備えたすべてのステーション デバイスが、MLPP 対応または MLPP 非対応として設定されます。ユーザ プロファイルが適用されるデバイスは、そのデバイスから開始される優先コールに関して、そのユーザの優先レベルを継承します。デフォルト ユーザが割り当てられたデバイスは、デフォルト ユーザの標準優先レベルを継承します。
発信側に関連付けられたコーリング サーチ スペース(CSS)の設定によって、ユーザが優先パターンをダイヤル(優先コールを発信)できるかどうかが制御されます。Cisco Unified CallManager には、許可される最高の優先順位値を明示的に示す設定はありません。
次の例に、第 3 のユーザにプライオリティ レベルの優先コールをかけようとする 2 人のユーザについて、優先コールへのアクセスの違いを示します。
例
図14-14 に、優先順位パターン用の MLPP 番号計画アクセス制御の例を示します。
図14-14 優先順位パターン用の MLPP 番号計画アクセス制御の例
次の表で、この例の 3 人のユーザを定義します。
|
|
|
|
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)に対してブロックされることを決定し、コール処理は Unauthorized Precedence Announcement(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 CallManager の管理ページでは、単一のダイヤル パターンを介して複数のゲートウェイへコールをルーティングし、使用可能なチャネルを検索するようにルート リストおよび関連するルート グループを設定することができます。ルート リストには、ルート リストがコールをルーティングできる多数のトランク リソースがありますが、個々のリソースは多数のゲートウェイに分散している場合があります。
ゲートウェイの集合(つまり、ルート リストとルート グループの設定)で使用可能なトランク リソースを特定できない場合、Cisco Unified CallManager は、集合内で優先レベルの低い共有リソースのプリエンプションの開始を試みます。ルート リストとルート グループの設定でプリエンプション対応のチャネルをさらに検索する方法は 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 つの方法を示しています。
図14-15 に、ルート リストとルート グループを使用して使用可能なトランク デバイスをハントする MLPP トランク選択の例を示します。
図14-15 MLPP トランク選択(ハント)の例
方法 1 では、次の一連のイベントが発生します。
1.
フラッシュ レベルの着信優先コールがルート リスト RL に到達します。これには、ルート グループ RG1 だけが含まれています。
2.
ルート グループ RG1 には 3 つのトランク デバイスが含まれています。
RG1 内の 3 つのトランク デバイスのうち、トランク デバイス 1 とトランク デバイス 2 は通話中なので、システムは使用可能なトランク デバイス 3 にコールを発信します。
方法 2 では、次の一連のイベントが発生します。
1.
フラッシュ レベルの着信優先コールがルート リスト RL に到達し、まずルート グループ RG1 へ移動します。ここで、コールはトランク デバイス 1 へ送信されますが、トランク デバイス 1 は通話中です。
トランク デバイス 1 の場合、このデバイスを使用しているコールを差し替えるには、フラッシュよりも優先順位の高いコールである必要があります。
2.
コールはルート リスト 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 CallManager Serviceability システム ガイド 』および『 Cisco Unified CallManager Serviceability アドミニストレーション ガイド 』を参照してください。
優先コール用の CDR の録音
MLPP 優先コールは、Call Detail Records(CDR)を生成します。CDR は、優先コールの優先レベルを示します。
通常は、同じ優先レベルのコール レッグが適用されます。転送コールや会議コールでは優先レベルが異なる場合があるので、Cisco Unified CallManager CDR はコールの各レッグの優先レベルを示します。
Cisco Unified CallManager CDR は、差し替えられたコールの切断のプリエンプション値を記録します。
詳細については、『 Cisco Unified CallManager Serviceability システム ガイド 』および『 Cisco Unified CallManager Serviceability アドミニストレーション ガイド 』を参照してください。
コール転送
MLPP は、次のリストで説明しているように、コール転送機能と通信します。
•
コールの話中転送
–
オプションで、任意の MLPP 対応ステーションに対して事前設定の Precedence Alternate Party ターゲットを設定できます。
–
Cisco Unified CallManager は、コールに Precedence Alternate Party Diversion 手順を適用する前に、通常の方法で優先コールを転送する Call Forward Busy 機能を適用します。
–
着信優先コールの優先順位が既存のコールの優先順位と同じかそれより低い場合、コール処理は通常のコール転送機能を呼び出します。
–
優先コールの宛先ステーションがプリエンプション対応ではない場合(つまり、MLPP が設定されていない場合)、コール処理はコール転送機能を呼び出します。
–
システムは、転送された複数のコール間でのコールの優先順位を保存します。
–
着信優先コールの優先順位が既存のコールの優先順位より高い場合は、プリエンプションが実行されます。優先コールが送信されたステーションの電話が切られるまで、アクティブなコールによって差し替えられるコールの両方のユーザに、連続的なプリエンプション トーンが再生されます。電話を切ると、優先コールが送信されたステーションに優先順位呼び出し音が再生されます。宛先ステーションは、オフフックになると、優先コールに接続されます。
•
応答なし時のコール転送
–
コールの優先レベルがプライオリティ以上である場合、コール処理は、転送プロセスでコールの優先レベルを保存し、転送先のユーザの差し替えを試みます。
–
優先コールの宛先に対して Alternate Party が設定されている場合、コール処理は、Precedence Call Alternate Party タイムアウトの期限が切れた後に、優先コールを代替パーティに転送します。
優先コールの宛先に対して Alternate Party が設定されていない場合、コール処理は、優先コールを Call Forward No Answer 設定に転送します。
–
優先コールは通常、ボイスメール システムではなくユーザにルーティングされます。管理者は、優先コールがボイスメール システムに転送されるのを避けるため、Use Standard VM Handling For Precedence Calls エンタープライズ パラメータを設定します。詳細については、「MLPP のエンタープライズ パラメータの設定」を参照してください。
コール転送
MLPP は、コール転送機能と通信します。ブラインド転送と打診転送の場合は、コンサルト コールも含め、転送されるコールの各接続が、コールが確立されたときに接続に割り当てられた優先順位を維持します。
共有回線
MLPP は、共有回線と通信します。保留中のコールがある共有回線表示は、同じ電話番号(DN)を持つ別の端末への優先順位の高いコールを確立するため、差し替えられる可能性があります。この場合、保留中の元のコールは切断されず、優先コールが接続されます。優先コールが終了すると、ユーザは保留中の元のコールを取得できます。
コール待機
MLPP は、次のリストで説明しているように、コール待機機能と通信します。
•
ネットワーク リソースの不足のためコール待機ステータスと MLPP 優先コールの間に競合が発生した場合、コールは差し替えられます。
•
コール待機が設定された宛先ステーションに優先コールが発信されると、次のイベントが発生します。
–
要求された優先順位が既存のコールの優先順位よりも高い場合、既存のコールは差し替えられます。宛先ユーザがプリエンプション対応ではない場合、コール処理は、通常のコール待機機能とアラートを呼び出します。優先コールの優先レベルがプライオリティ以上である場合、宛先ユーザは優先コール待機トーンとケイデンスを受信します。
–
要求された優先レベルが既存のコールの優先順位と同じである場合、コール処理は、通常のコール待機機能を呼び出します。優先コールの優先順位が標準である場合、コール処理は、標準コール待機トーンで宛先に警告します。優先コールの優先順位がプライオリティ以上である場合、コール処理は、優先コール待機トーンで宛先に警告します。
–
要求された優先レベルが既存のコールの優先順位より低い場合、コール処理は、通常のコール待機機能を呼び出します。優先コールの優先順位が標準である場合、コール処理は、標準コール待機トーンで宛先に警告します。優先コールの優先順位がプライオリティ以上である場合、コール処理は、優先コール待機トーンで宛先に警告します。
–
デバイスに複数の表示がある場合、宛先ユーザは、優先順位の低いコールを保留にし、優先順位の高いコールに受信応答することができます。優先順位の高いコールが終了すると、宛先ユーザは、保留にした優先順位の低いコールを再開できます。
コール保存
Cisco Unified CallManager コール保存機能によって保存される MGCP トランク コールまたは接続は、コール保存機能が呼び出された後、優先レベルと MLPP ドメインを保存します。デバイスが Cisco Unified CallManager に登録された後、システムは、保存されたコールを Cisco Unified CallManager システムのデバイス層だけに保存します。そのため、保存されたコールは 2 つの半々のコールとして扱われます。これらのデバイスでプリエンプションが実行された場合、一方のレッグだけが他方のレッグへのプリエンプション プロトコルに従うことができます。システムは、RTP ポートのクローズによってしかコールの終了を検知できません。
自動代替ルーティング
AAR の拡張機能である Automated Alternate Routing (AAR) for Insufficient Bandwidth 機能は、ロケーションの帯域幅が不十分で Cisco Unified CallManager がコールをブロックした場合に、代替番号を使用し、Public Switched Telephone Network(PSTN)またはその他のネットワークを介してコールを再ルーティングするため、自動的にフォールバックするメカニズムを提供します。この機能を使用すると、発信者は電話を切ったり着信側に再びダイヤルする必要がなくなります。
優先コールの試みが AAR サービスの起動条件と一致した場合、優先コールは AAR 設定の指定に従い、PSTN またはその他のネットワークを介して再ルーティングされます。Cisco Unified CallManager は、コールがルーティングされたネットワーク インターフェイスの MLPP 表示対応および MLPP プリエンプション対応の設定に基づいて、コールが最初から PSTN またはその他のネットワークを介してルーティングされた場合と同じように、コールの優先順位を処理します。
自動代替ルーティングの設定の詳細については、『 Cisco Unified CallManager アドミニストレーション ガイド 』の「自動代替ルーティングのグループ設定」を参照してください。
MGCP と PRI プロトコル
MLPP は、Cisco Unified CallManager が MGCP プロトコルを使用して制御し、MLPP プリエンプション対応として設定されたターゲット Voice over IP ゲートウェイ上の T1-CAS および T1-PRI(北米)インターフェイスに対してだけ、共通ネットワーク ファシリティ プリエンプションをサポートします。
セキュアなエンドポイントとセキュアな通信
従来の米国国防総省(DOD)の TDM ネットワークでは、従来のアナログ STU(secure telephone units)と BRI STE(secure telephone equipment)をセキュアなエンドポイントとして使用しています。これらはセキュアな通信には重要です。新しく開発された IP STE でも、従来の設備の必要性を削減するためのサポートが必要です。Cisco Unified CallManager は、これらのデバイスの Skinny Client Control Protocol をサポートしています。モデム リレーは、V.150 プロトコルを使用しており、セキュアな通信を提供しています。