アプリケーション ノート:
Cisco Unified Communications Manager への着信コールを発信者 ID に基づいてブロックする
はじめに
発信者番号に基づいてコールをブロックする機能は、勧誘電話や迷惑電話などがユーザに到達しないようにするため、高い需要のある機能です。このアプリケーション ノートでは、Cisco Unified Communications Manager v8.0 以降を使用してコール ブロッキングを設定する方法を説明します。
対象読者:
本書は、Cisco Unified Communications Manager 環境でのコール ルーティングに習熟している管理者を対象としています。この機能を実装するには、管理者は発信者 ID ブロック機能を実装するために、既存のダイヤル プラン、コール ルーティングおよびコール フローについて十分な知識を持っている必要があります。管理者は、パーティション、コーリング サーチ スペース、トランスレーション パターンを理解している必要があります。
コール フロー:
従来、Cisco Unified Communications Manager 環境に着信したコールは着信側に基づいて処理され、発信者番号ではルーティングの判断は行われませんでした。Cisco Unified Communications Manager v8.0 以降では、管理者は一般的なコール ルーティング手法を使用して、着信者番号だけでなく発信者番号を基準としてコールを受理または拒否できるようになりました。
CUCM 8.0 では、トランスレーション パターンに、[Route Next Hop by Calling Party Number] チェックボックスがオンになっているインバウンド トランスレーション パターンとの照合後、発信者番号に対して番号分析を実行し、一致した場合に管理者がコールをブロックできるようにします(発信者番号によるフィルタ機能を利用するためには、対象とするすべてのディレクトリ番号を、コーリング サーチ スペースでアクセスできるパーティションに含めておく必要があります。着信者番号は <none> パーティションに含めることはできません)。
発信者番号がブロックするトランスレーション パターン番号に一致しない場合、CUCM はコールの処理を続け、コールを宛先ディレクトリ番号にルーティングします。
構成:
発信者番号のコール ブロッキングの「フィルタ リスト」の作成に必要なパーティションとコーリング サーチ スペースは、ほんのわずかです。コール フローについては、上の図 1 を参照してください。
1) 「Inbound_Calls」と「Filter_List」という 2 つのパーティションを作成します。
2) 「Gateways」と「To_Filter_List」という 2 つのコーリング サーチ スペースを作成します。
3) 「Inbound_Calls」パーティションを「Gateways」コーリング サーチ スペースに追加します。
注:「Gateways」コーリング サーチ スペースにはディレクトリ番号を含むパーティションを指定できません。そうしないと、コールが発信者フィルタを通過せずに、直接ルーティングされてしまいます。
4) 「Filter_List」パーティションを「To_Filter_List」コーリング サーチ スペースに追加します。
5) トランスレーション パターン ! を「Inbound_Calls」パーティションに作成します。コーリング サーチ スペースを「To_Filter_List」に設定して、[Route Next Hop By Calling Party] をオンにします。
注:パターン ! はすべての着信コールに一致させるために使用され、コールを「Filter_List」パーティションにルーティングして、発信者のマッチングを行います。
6) トランスレーション パターン ! を「Filter_List」パーティションに作成します。コーリング サーチ スペースで、ブロックされないコールを宛先にルーティングするように設定します。
「Filter_List」パーティションの !を使用して、明示的にブロック対象として指定されていない発信者番号をルーティングします。コーリング サーチ スペースはコールを電話のパーティションにルーティングして、通常のコール ルーティングを行います。
7) 一部のコールは、発信者 ID または制限された発信者 ID がない状態で着信します。発信者 ID がないコールを許可するには、<none> または空白のトランスレーション パターンも必要です。<none> トランスレーション パターンを定義しない場合、発信者 ID がないすべてのコールは拒否されます。
8) 通常のパターン マッチングを使用して、ブロックする発信者番号と一致させるトランスレーション パターンを作成します。800 から始まる発信者番号を持つすべてのコールをブロックするには、「800!」というトランスレーション パターンを Filter_List Partition に作成します。ルート オプションの [Block this pattern] に、適切な理由コードとともに設定します。
または、コールを完全に拒否するのではなく、[Called party transform Mask] フィールドにディレクトリ番号を設定して、これらのコールを特定の DN にリダイレクトできます。たとえば、コールがブロックまたは拒否されたことを示すメッセージをコールに対して自動応答で送信できます。
9) 最後のステップは、「Gateways」コーリング サーチ スペースを、発信者 ID に基づいて着信コールをブロックする入力ゲートウェイに割り当てることです(H323、MGCP、または SIP トランク)。
発信者 ID に基づくコール ブロッキングを既存システムに追加する:
すでにダイヤル プランを実施しているお客様は、発信者に基づくコール ブロッキングを簡単に追加できます。ゲートウェイまたはトランクから Communication Manager にコールが着信すると、このゲートウェイまたはトランクに割り当てられたコーリング サーチ スペースに基づいてコールがルーティングされます。上記の設定ステップに従って、管理者はシステムでの呼処理に影響を及ぼすことなく、ステップ 8 まででグローバルなトランスレーション パターンおよびブロックされた番号のパーティションを設定できます。ただし、最後のステップは営業時間終了後またはメンテナンス期間に実施してください。コーリング サーチ スペースを変更した後は、トランクまたはゲートウェイをリセットして変更を反映させる必要があるためです。
SIP トランク上での「匿名」コールのブロック:
SIP トランクの普及が急速に進み、匿名の発信者の「From:」ヘッダーには「anonymous」または「unavailabe」という文字が設定されます。Cisco Unified Communications Manager 番号分析エンジンは、数字以外の文字列のマッチングに対応していないため、「anonymous」という名前は有効な文字列として通過します。「anonymous」または「unavailable」の発信者を正しく特定してブロックするには、anonymous_clid.lua スクリプトを、ブロックする匿名コールを受信する SIP トランクに適用します。使用方法は、スクリプト内部に含まれています。
※日本語訳注:更新される可能性があるため、スクリプトは英語版を参照してください。