Automated Signal Processing Rules

System administrators can specify Server-Wide and Cluster-wide Signal Rules. Use the WebAdmin Interface to open the Real-Time pages in the Settings realm, and click the Rules link.

System and Domain Administrators can specify Account Rules using links on the Account Settings WebAdmin Interface pages.

Account users can specify their Rules themselves, using the WebUser Interface. System or Domain Administrators can limit the set of Rule actions a user is allowed to specify.

System and Domain Administrators can specify Domain-Wide Rules using the Rules links on the Domain Settings pages.

See the generic Automated Rules section to learn how to set Rules.

Each Rule can use universal conditions specified in the Rules section.
Additionally, the following Rule conditions can be used in Signal processing Rules:

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

This condition checks if the Request method is or is not equal to the specified string.

Sample:

Operation

is

This condition will be met for all INVITE Requests.

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

This condition checks if the Request SDP type address is (or is not) equal to the specified string.
The SDP type is AV if the request methoid is INVITE and it contains at least one audio or video media channel;
The SDP type is IM if the request method is MESSAGE or if the request method is INVITE and it contains an IM channel.
The SDP type is an empty string in all other cases.

Sample:

CallType

is

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

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

This condition checks if the Request From address is (or is not) equal to the specified string.

Sample:

From

is

This condition will be met for all signals coming from any account on any of communigate.com subdomains.

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

The same as above, but the Request To address is checked.

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

The same as above, but the instead of the address, the "address comment" (the real name) included in the From address is checked.

Sample:

'From' Name

is

This condition will be met for Requests with the following From: addresses:
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

This condition checks the Request authentication. If the Request has been authenticated by this CommuniGate Pro Server, the authenticated Account name (account@domain) is compared with the specified string.

Sample:

Authenticated

is

This condition will be met for all signals coming from any account on any of communigate.com subdomains.

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

This condition checks the aggregated presence of the request target. This condition can be used in the Domain- and Account- level Rules only.
The Presence is one of the strings online, busy, away. The Presence is an empty string when the call target is offline.

Sample:

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).

Each Rule can have zero, one, or several actions. If a Request meets all the Rule conditions, the Rule actions are performed.

You can use all universal actions described in the Rules section. This section describes the Rule actions that can be used in Signal Rules:

Stop Processing

This action should be the last one in a Rule. Execution of this Rule stops and no other (lower-priority) Rules are checked for this Signal at this time. Signal processing proceeds.

Discard Rules

This action should be the last one in a Rule. Execution of this Rule stops and no other (lower-priority) Rules are checked for this Signal, and all remaining Rules (scheduled to apply at later times or if the Signal fails) are removed, too. Signal processing proceeds.

Redirect to addresses

The Signal is redirected to one or several specified addresses: the current Signal "destination set" is cleared, and the specified addresses form the new "destination set".
Each address should be specified as a sip:, sips:, or tel: URI. If several addresses are specified, they should be separated with the comma (,) sign.

Sample:

Operation	is
Authenticated	is not

Redirect to

sip:adManager@domain.com

This Rule will direct all INVITE Signals to the adManager@domain.com address, unless the Signal authenticated source is adManager@domain.com.
You can use this Rule to implement an advertizing server: the adManager@domain.com Account can start a PBX application that will play some media to the caller, and then, acting as a B2BUA, will connect the caller with the original destination. The calls made by that application will have adManager@domain.com as their autenticated source, so this Rule will not redirect them.

Fork to addresses

Same as Redirect to, but the specified addresses are added to the current "destination set" without clearing it first.

The Signal component records system-wide Rules activity in the Log. Set the Signal Log Level to Low-Level or All Info to see the Rules checked and the actions executed.