Functional group (sipkit)
Description
Defines a group of SIP user accounts whose call is serviced by the group algorithm.
The following feature types are available: forwarding group, failover group, call option setting group, parallel call group, and chief-secretary group.
Fields
{
"id": uuid,
"name": str,
"type": str,
"enabled": bool,
"cascade": bool,
"priority": int,
"details": object,
"opts": {
"title": str,
"comment": str
},
"ext": {
"ct": date,
"lwt": date
}
}
Specification | Description |
---|---|
Field: |
Identifier. Can be specified at creation, otherwise generated by the system. |
Field: |
Group name. Displayed during tracing. |
Field: |
Group Type. Specific settings are set for each type in the field 'details'.
|
Field: |
Group switch. |
Field: |
Cascading mode switch. |
Field: |
Group Application Priority. |
Field: |
Typed object. More information in GroupTypes. |
Field: |
Composite field |
Field: |
Arbitrary header |
Field: |
Arbitrary comment |
Field: |
Composite field allowing to extend the composition with arbitrary keys and values |
Field: |
Object creation time |
Field: |
Time of last modification of the object |
Types of groups
Depending on the group type set, a special 'details' parameter is set and the corresponding logic is implemented during the call.
Forwarding group (redirect)
Call Forwarding Group.
The 'filter_from' filter is applied to the number of the original originating caller, excluding call forwarding and transfers. The number of the call forwarder can be filtered by the field 'filter_by'.
Field: filter_from Mode: in Type: str Default: * |
Source number filter mask. The result of the modification by the routing rules applied in the previous steps is checked. Initially the source number from the username field of the Referred-By header, and in its absence from the From header, SIP-request INVITE, or the result of a more complex definition of the initiator subscriber number (e.g. sipuser phonenumber, the result of applying sipuser extension, callerid to esg conversion rules, etc.) is checked. Filter operation modes. |
---|---|
|
Mask-filter the number of the caller who forwarded the call. |
|
Forwarding number. |
{ "filter_from": "*", "filter_by": "*", "redirect_number": "122" }
Failure Group (reject)
Call Denial Group.
The 'filter_from' filter is applied to the number of the original originating caller, excluding call forwarding and transfers. The number of the call forwarder can be filtered by the field 'filter_by'.
Field: filter_from Mode: in Type: str Default: * |
Source number filter mask. The result of the modification by the routing rules applied in the previous steps is checked. Initially the source number from the username field of the Referred-By header, and in its absence from the From header, SIP-request INVITE, or the result of a more complex definition of the initiator subscriber number (e.g. sipuser phonenumber, the result of applying sipuser extension, callerid to esg conversion rules, etc.) is checked. Filter operation modes. |
---|---|
|
Mask-filter the number of the caller who forwarded the call. |
|
Response code. |
|
Reason for rejection. |
{ "filter_from": "*", "filter_by": "*", "sip_code": 603, "sip_reason": "Some reason" }
Call option setting group (options)
The group generates call option changes for the shoulder and child shoulders (calls initiated by forwarding and/or parallel calls within the current routing process).
Specifically, it allows you to establish:
-
dialog_timeoutsec
- Limit on the duration of a call (from 5 to 7200). -
fork_timeoutsec
- specific shoulder call time (from 3 to 180). -
fork_fromuri
- a representation of the caller.
The set value is applied to all child shoulders unless an individual setting from another group is applied to them in the continuation of the routing process.
Default value - does not apply the group parameter. Value "undefined"
- resets the previously applied parameter.
The 'filter_from' filter is applied to the number of the original originating caller, excluding call forwarding and transfers. The number of the call forwarder can be filtered by the field 'filter_by'.
Field: filter_from Mode: in Type: str Default: * |
Source number filter mask. The result of the modification by the routing rules applied in the previous steps is checked. Initially the source number from the username field of the Referred-By header, and in its absence from the From header, SIP-request INVITE, or the result of a more complex definition of the initiator subscriber number (e.g. sipuser phonenumber, the result of applying sipuser extension, callerid to esg conversion rules, etc.) is checked. Filter operation modes. |
---|---|
|
Mask-filter the number of the caller who forwarded the call. |
|
List of numbers that activate the group when a call is received. |
|
Maximum dialog duration, seconds. A value of |
|
Shoulder call timeout, seconds. Applies to all shoulders that are children of the current call within the current routing process. A value of |
|
Caller Presentation. Applies to all shoulders that are children of the current call within the current routing process. Only username and displayname. |
{ "filter_from": "*", "filter_by": "*", "numbers_to": ["205","206"], "fork_timeoutsec": 3, "fork_fromuri": "\"DISPLAY NAME\" <sip:username@domain>" }
Parallel call group (parallel)
Call parallelization group depending on the mask of the call initiator and optionally the call transfer initiator.
Any call to the account number specified in the 'numbers_to' list results in a simultaneous call to the parallel numbers specified in the 'numbers_parallel' field.
Any is direct, group, translated, forwarded, from a script.
In case such a number is called as a parallel number from another functional group, the application of the parallel numbers set for it depends on the cascade property of the functional group.
Is a common alternative to setting up an individual parallel call in SIP user account.
In this case, the call in the statistics is bound to the real owner of the destination number.
The 'filter_from' filter is applied to the number of the original originating caller, excluding call forwarding and transfers. The number of the call forwarder can be filtered by the field 'filter_by'.
Field: filter_from Mode: in Type: str Default: * |
Source number filter mask. The result of the modification by the routing rules applied in the previous steps is checked. Initially the source number from the username field of the Referred-By header, and in its absence from the From header, SIP-request INVITE, or the result of a more complex definition of the initiator subscriber number (e.g. sipuser phonenumber, the result of applying sipuser extension, callerid to esg conversion rules, etc.) is checked. Filter operation modes. |
---|---|
|
Mask-filter the number of the caller who forwarded the call. |
|
List of numbers that activate the group when a call is received. |
|
List of numbers used to initiate a parallel call. In either case, calls will be sent to each of the target numbers once. |
{ "filter_from": "*", "filter_by": "*", "numbers_to": ["205","206"], "numbers_parallel": ["205","206","207"] }
Chief-Secretary Group (chief)
When a call to the chief is received from numbers not on the direct access list, the secretaries are called.
The decision whether the initiator is allowed to make a direct call to the chief is made based on the filter applied to the number of the subscriber who transferred or forwarded the call to the chief.
At the same time, the group authorizes call interception, BLF subscriptions between the chief and secretaries, and places details on the incoming call in BLF notifications for display on the device panel so that the group subscribers can see the initiator of the call and can intercept.
Thus between the chief and the secretaries, there is no need to configure separate permissions rules featurerules for the following feature types:
* pickup
, callwaiting
, blf
, blf_details
- in all directions;
* intercom
, barge
- from the chief to the secretaries.
In order for the mode to work fully, it is necessary:
* enable the 'blf_details_enabled' option in the domain settings;
* set up BLF subscriptions on the chief’s and secretaries' phones as needed (so that the secretaries can see the chief’s status, the chief can see the secretaries' status);
* configure the chief and secretary phones to display information about the call initiator when a BLF message is received (Yealink: account.X.dialoginfo_callpickup=1, features.pickup.blf_visual_enable=1);
* restrict the use of BLF visualization on the chief and secretary phones to a specific list of numbers (Yealink: features.pickup.blf_visual.list=101,102,103 or any);
* if audio notification of a call to the chief’s number is required, set up the secretaries' phones to play a melody when receiving a BLF message (Yealink: features.pickup.blf_audio_enable=1), customize the melody, and specify restrictions on the use of BLF audio notification for a certain list of numbers (Yealink: features.pickup.blf_audio.list=101,102,103 or any).
With the above settings, the subscriber’s phone displays the incoming calls of the tracked subscriber on the display, providing an opportunity to intercept the selected one.
Interception is accomplished by sending an INVITE with the Replaces header (rather than calling subscriber function code, since it is not possible to specify a specific call to intercept in this mode).
There is an alternative setup with interception via subscriber function code:
* create subscriber function code with the type "intercept by number" and configure its availability in routing rules;
* set up interception support on the chief and secretaries' phones by setting the number of the corresponding ficacode (Yealink: account.x.direct_pickup_code);
* when setting up BLF subscriptions on the chief and secretaries' phones, specify an intercept number (the same subscriber function code) for each of them.
In order for the mode with interception via ficacode to work, you need to turn off the option on the phone (Yealink: account.X.dialoginfo_callpickup=0).
When using a 'intercept' type ficacode, it is not possible to specify a specific call to intercept if the monitored device receives multiple calls.
In this regard, in order to improve performance, it is advisable not to use granularity in BLF notifications by disabling the 'blf_details_enabled' option in the domain settings.
Field: mode Mode: in Type: str Default: cascade |
Operating algorithm. Possible options: * parallel - when calling the chief’s number from any number not mentioned in the group, the call is forwarded to both assistants in parallel.* cascade - when calling the chief’s number from any number not mentioned in the group, the call is forwarded sequentially to the first assistant, then to the second assistant.* direct - when calling the chief’s number from any number, the call goes through without forwarding. |
---|---|
|
Chief Number. |
|
First Assistant Number. |
|
Second assistant number. |
|
List of numbers directly going to the chief. Applies to the result of from/referred-by conversion by routing rules. |
|
Chief’s mobile number. The number is used to automatically publish the status of the subscriber participating in the dialog. Case example: a secretary connects the chief on a mobile number sequentially to multiple callers. Extends the list of external numbers with state tracking, the list of which is set in domain settings. |
{ "mode": "cascade", "chief_number": "101", "assistant1_number": "102", "assistant2_number": "103", "direct_numbers": ["115", "123"] }
Random group (custom)
It is used to implement project logic.
Field: filter_from Mode: in Type: str Default: * |
Source number filter mask. The result of the modification by the routing rules applied in the previous steps is checked. Initially the source number from the username field of the Referred-By header, and in its absence from the From header, SIP-request INVITE, or the result of a more complex definition of the initiator subscriber number (e.g. sipuser phonenumber, the result of applying sipuser extension, callerid to esg conversion rules, etc.) is checked. Filter operation modes. |
---|---|
|
Mask-filter the number of the caller who forwarded the call. |
|
List of numbers that activate the group when a call is received. |
|
Project Group Type. Defines a set of other detail parameters. |
Additionally
Filter operation modes
Mode | Description |
---|---|
|
The value to be subjected to the conformance check is passed through the filter character by character.
If it is necessary to specify one of the service characters as a target character, it should be enclosed in square brackets, e.g. For example, |
|
The
Field values in the table can be used as field values:
The tabular modifier may be used in combination with other character mode control commands. For example, |
|
The pattern is applied to the original value Pattern. The structure of a regex pattern value: For example,- significance:
All standard regular expression rules can be applied when forming Pattern patterns. |
|
The value subject to compliance checking is a numeric integer and is within the specified numeric range. The structure of the dia-template value: For example,- significance: |