シグナルの自動処理ルール

システム管理者は、サーバーワイドのシグナルの自動処理ルール（シグナルルールと呼ぶこともあ ります） とクラスタワイドのシグナルの自動処理ルールの設定が可能です。設定する場合、 WebAdmin インターフェイスの［Settings］ セッションの［Signals］ ページを開き、［Rules］ リンクを クリックします。

また、システム管理者とドメイン管理者は、WebAdmin インターフェイスの［Account Settings］ ページのリンクを使ってアカウントのルールを設定できます。

アカウントのユーザーはWebUser インターフェイスで、自分のアカウントのルールを設定できます。 なお、システム管理者またはドメイン管理者は、ユーザーが指定できるルールのアクションを制限で きます。

システム管理者とドメイン管理者は、WebAdmin インターフェイスの［Domain Settings］ ページの ［Rules］ リンクを使ってドメインワイドルールを設定できます

ルールの設定については、詳しくは自動処理ルールのセクションを参照してください。

シグナルの自動処理ルールでは、一般条件を使用できます。一般条件についてはルールのセクション を参照してください。
シグナルの自動処理ルールでは、一般条件のほか次のような条件（シグナルの自動処理ルール独自の 条件）を使用できます。

Operation [is | is not | in | not in] string

string （右端のフィールド） に文字列を指定し、その文字列が要求のメソッド（Method）の 値（INVITE など）と一致するか（is）、一致しないか（is not）をチェックできます。

下は、例です。

Operation

is

上の条件は、要求がINVITE 要求だった場合に満足されます。

CallType [is | is not | in | not in] string

stringに文字列を指定し、その文字列が要求のSDP （セッション記述プロトコル） タイプと 一致するか（is）、一致しないか（is not）をチェックできます。
要求のメソッドがINVITE で、その要求に音声メディアチャンネルまたはビデオチャンネル が少なくても一つ格納されている場合、SDP タイプ（ コールタイプ） はAV です。したがっ て、この種の要求をチェックしたい場合、stringに"AV" を指定します。
要求のメソッドがMESSAGE の場合、または要求のメソッドがINVITE で、その要求にIMチャンネルが格納されている場合、SDP タイプはIM です。したがって、この種の要求を チェックしたい場合、stringに"IM" を指定します。
上記以外の場合、SDP タイプは空白です。したがって、空白を指定します。

下は、例です。

CallType

is

This condition will be met for all audio/video INVITE Requests.

From [is | is not | in | not in] string

stringに文字列を指定し、その文字列が要求のFrom アドレスと一致するか（is）、一致しな いか（is not）をチェックできます。

下は、例です。

From

is

上の条件は、シグナルがstalker.com のいずれかのサブドメインのアカウントから送信された ものだった場合、満足されます。

To [is | is not | in | not in] string

上記のFrom 条件と基本的には同じですが、この条件では要求のTo アドレスをチェックでき ます。

'From' Name [is | is not | in | not in] string

上記のFrom 条件と基本的には同じですが、From アドレスの中の「アドレスコメント（実 名）」をチェックできます。

下は、例です。

'From' Name

is

上の条件は、要求のFrom: アドレスが次の場合に満足されます。
From: <sip:jsmith@company.com> (John J. Smith)
From: "Bill J. Smith" <sip:b.smith@othercompany.com>
From: Susan J. Smith <sips:susan@thirdcompany.com>

Authenticated [is | is not | in | not in] string

この条件は、認証された要求に関する条件です。stringに文字列（account@domain の形式 のアカウント名） を指定し、そのアカウント名がCommuniGate Pro サーバーによって認証済 みであるかどうかをチェックできます。

下は、例です。

Authenticated

is

上の条件は、シグナルがstalker.com のいずれかのサブドメインのアカウントから送信された ものだった場合、満足されます。

Presence [is | is not | in | not in] string

この条件では、要求のターゲット（送信先のエンティティ） の合計プレゼンスをチェックで きます。stringには、プレゼンスの値（文字列） を指定します。この条件は、ドメインワイ ドルールまたはアカウントレベルのルールでのみ使用できます。
プレゼンスの値としては、　online、busy、away を指定できます。ターゲットがオフライン （offline） かどうかをチェックしたい場合、値を空白にしておきます。

下は、例です。

Presence

in

Active Devices [is | is not | less than | greater than | in | not in] number-string

This condition checks the total number of Registered Devices for the request target. This condition can be used in the Domain- and Account- level Rules only.
When a call is forked to a different destination, the total number of Registered Device is increased by the number of registred devices for the new request target.
When a call is redirect to a different destination, the total number of Registered Device is reset to zero, and then it is increased by the number of registred devices for the new request target.

Device Type [is | is not | in | not in] string

This condition checks the type of device sending the request (the User-Agent request field).

一つのルールには、単一もしくは複数のアクション（またはアクションなし） を定義できます。要求 について、ルールの条件がすべて満足された場合、そのルールに定義したアクションが実行されま す。

ここでは、シグナルのルールのアクションについて説明します。このほか、一般アクションも使用できます。一般アクションについては、ルールのセクションを参照してください。

Stop Processing

このアクション（処理終了）についてはルールのセクションを参照してください。このアク ションでは、シグナルがカレントのターゲットに送信されます。

Discard Rules

このアクションは、ルールの最後に指定しなければなりません。このアクションによりルー ルが停止し、他のルール（優先度が下位のルール） は一切、カレントのシグナルには適用さ れません。また、残りのルール（現在より以降に適用が予定されているルール、またシグナ ル処理が失敗したときに適用されるルール） もすべて削除されます。このアクションによる ルールの停止後、シグナルが処理されます。

Redirect to addresses

このアクションでは、アドレス（単一または複数） を指定し、そのアドレスにシグナルをリ ダイレクトできます。シグナルのカレントの「デスティネーションセット（最終送り先）」 は消去され、指定したアドレスがシグナルの新規の「デスティネーションセット」になりま す。
アドレス（URI） は、その前にsip:、sips:、tel: のいずれかを付加して指定します。複 数指定するときには、各アドレスをコンマ（,）で区切ります。

下は、例です。

Operation	is
Authenticated	is not

Redirect to

sip:adManager@domain.com

上のルール（条件が2 つ、アクションが1 つ） の場合、認証ソースがadManager@domain.com のシグナルを除き、INVITE シグナル（要求） がすべてアドレスadManager@domain.com address にリダイレクトされます。
上のルールを使ってアドバタイジングサーバー（広告提供サーバー） を実装できます。つまり、まずアカウントadManager@domain.com によってPBX アプリケーションが起動され、そ のアプリケーションによって着信側に何らかの広告メディアが再生・提供されます。その 後、アプリケーションはB2BUA （Back to Back User Agent） として動作し、発信側を本来の デスティネーションに接続します。ここで、アプリケーションによって実行されたコール （呼） は、adManager@domain.com を認証ソースとしているためadManager@domain.com にはリ ダイレクトされません。

Fork to addresses

上記のRedirect to アクションと基本的には同じです。ただし、指定したアドレスがカレ ントの「デスティネーションセット」に追加され（フォーク処理）、その後、消去されます。

サーバーワイドルールのアクティビティはシグナルコンポーネントにより自動的にログに記録されま す。ログレベルを［Low-Level］または［All Info］に設定しておくと、使用されたルールと実 行されたアクションをログで確認できます。