Each signal Rules has its stage and priority. The stage specifies when the Rule should be applied:
- immediately when the Signal is received
- after the Signal is being processed for some time
- when the Signal fails with the No Answer, Busy, or some other error condition.
Within each stage the Rules are applied according to their priority.
When Server, Cluster, Domain, and Account Rules are "merged", they are grouped based on the stage value.
Within each stage, the Rules are applied in the following order:
- the Server and Cluster Rules with the priority > 5
- the Domain Rules with the priority > 5
- all Account Rules
- the Domain Rules with the priority <= 5
- the Server and Cluster Rules with the priority <= 5
Note: when Signal processing starts, all Server and Cluster Rules for the "immediate" stage are applied first,
and only then processing continues. The Signal can be directed to a local Account, and
the Account and Account Domain Rules are "merged" with the Server and Cluster Rules.
But at that moment all Server and Cluster Rules for the "immediate" stage have been already applied and removed from the "merged" set.
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:
-
- CallType [is | is not | in | not in] string
- This condition checks if the Request SDP type is (or is not) equal to the specified string.
The SDP type is AV if the request method 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:
-
- Target Address [is | is not | in | not in] string
- This condition checks if the Request URI is (or is not) equal to the specified string.
- Sample:
-
- 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:
-
- To [is | is not | in | not in] string
- The same as above, but the Request To field 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:
-
- 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:
-
- 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:
-
- 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 registered 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 registered 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).
- Request Field [is | is not | in | not in] string
- The string must contain the Request field name and the field data picture, separated with the colon (:) symbol.
This condition compares the specified request field data with the data picture. Only simple, unstructured request fields can be compared.
- Sample:
-
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.
To redirect the Signal into a PBX application you can use the address #myProgram
to run the application myProgram on behalf of the Signal authenticated source.
- Sample:
-
- Fork to addresses
- Same as Redirect to, but the specified addresses are added to the current "destination set" without
clearing it first.
- ParlayDirect parameters
- ParlayNotify parameters
- These actions implement the "CallDirection" and "CallNotification" ParlayX Interfaces.
The parameters setings specifies the request operation to use, the Parlay "correlator", and the URL to send the request to.
Parameter strings for Execute URL, Send IM,
Send Push, Write To Log actions can include "macro" - symbol combinations that are substituted
with actual data before the parameter is used with the Signal Rule action.
The following symbol combinations are available:
- ^F is substituted with the request From address (including the "Real name" part, decoded and converted to UTF-8)
^E is substituted with the request From address (the E-mail address only)
^t is substituted with the RFC822-formatted current-time.
^I is substituted with the request Call-ID.
^R is substituted with the request To address (the E-mail address only)
^M is substituted with the request Method.
^U is substituted with the request URL.
^^ is substituted with a single ^ symbol.
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.
|