...

This section describes terms and definitions used in telephone calls routing (hereinafter referred to as call routing) by the system and the principles of its configuration.

Terms and definitions

• Alias (Subscriber) — set describing a telephone number associated with an interface within a certain virtual PBX (domain) and various additional attributes (category, subscriber group, services) within the ECSS-10 system. In fact, it describes a virtual PBX subscriber connected to a certain port and having a certain set of parameters specific to it.
• Bridge — virtual gateway that connects virtual PBXs. The term "bridge" was introduced to create means of controlling connections between virtual PBXs. Calls between virtual PBXs of the same ECSS-10 system are routed within this system via bridge. At the same time, inter-station connecting lines are not involved. The bridge is presented in the form of two interfaces connected to each other. Each interface is declared in its own virtual PBX. For a bridge, as for a classic trunk, various types of restrictions can be set, for example, the number of channels, which gives a limit on the number of simultaneously established connections between virtual PBX and allows normalization of the load.
• Customer — the customer from the point of view of the telephone network. In fact, this is a subscriber who has a contract with his individual number, to whom communication services are provided by one or more telephone numbers/ports. There is no such entity in the ECSS-10 system as a switching platform, but it exists at the level of the billing system and at the level of the ECSS-10 management system.
• Direction — several interfaces through which it is possible to establish communication with a certain recipient. 
  Load balancing in the direction and the choice of an alternative route are carried out precisely between the interfaces of the same direction. If one interface is unavailable in the direction, then an attempt is made to establish a connection via the next interface in the list. Load balancing is performed based on information about the interface load, which is periodically provided by the interface control adapter.
• Interface — set describing a resource or a group of resources through which a telephone call passes within a certain routing context within the ECSS-10 system (for example, a certain port on an access gateway, a port on a media gateway, a channel on a trunk gateway, a bundle of channels, etc.).
  There is a distinction between the interface of the call initiator — the "originating" interface and the interface of the call recipient — the "terminating" interface.
• Numbering plan — set of addresses (phone numbers) within a virtual PBX.
• Routing context — set of routing rules unique in the routing domain, within which the interface of the called subscriber is defined.
  There are two types of routing contexts: local and transit.
• Routing process — process based on the available information about the "originating" interface, the telephone number of the called subscriber and other parameters, the "terminating" interface is searched for to establish a connection between the interfaces of the initiator and the recipient of the call.

• Routing rule — description of the process of converting and resolving call data and obtaining information about the alias and the interface of the called subscriber. Always exists within a specific context in the routing domain.

  The routing rule is described by:

  1. Conditions — set of parameters that a call must satisfy: the caller's number (template),the category, the number of the called subscriber (template), number type, time of day, day of the week, and more;
  2. Actions — when the rule is triggered, the call parameters can be modified: the number of the called subscriber, the number of the caller, the subscriber group;
  3. Result — the rule can return the following results:
     1. Subscriber B is local, the desired alias and the interface of the called subscriber;
     2. Subscriber B external, subscriber B number parameters, called subscriber interface (direction);
     3. Change the routing context. In this case, the context is changed, after which the routing is performed again;
     4. Routing is not possible.
• Subscriber profile — alias parameters within the virtual PBX.
• Telephone calls routing — process of determining the destination interface for a specific call based on information about the interface of the call source, information about the caller's and called subscriber's phone number, caller category, time of day and day of the week.

• Trunk group — interface that combines several connecting lines. In the ECSS-10 system, the interface can be a display of a specific channel or a set of channels — a bundle. The properties of the "trunk interface" describe the order of channel selection in the bundle.

• Virtual PBX (domain) — complex that groups a variety of routing contexts, interfaces and aliases. The closest equivalent is a description of the numbering and routing plan within the framework of a classical telephone exchange for traditional networks.

Telephone call routing

The purpose of the routing is to find the interface of the called subscriber to address the call to him.

...

• if according to the rule it is determined that the call needs to be addressed to a local subscriber or to an external direction, then the corresponding routing is performed;
• if the outgoing direction is not available, the call will be redirected to the backup direction (the backup direction must be configured);
• if it is determined that there is not enough data for routing, a result is returned that reports the incompleteness of the number: number_incomplete;
• if the current context changes, routing will continue in the specified context, processing in which will again begin with checking the call selection conditions;
• if the call was forwarded, then re-routing will be performed for a new call (the subscriber who forwarded the call and the subscriber to which the call was forwarded must have a route between them);
• if no matching rule was found in the context, a routing error is returned.

General scheme of telephone call flow through ECSS-10 routing

General scheme of telephone call flow is shown in Figure 1.

Image RemovedImage Added

Figure 1 — General scheme of telephone call flow

...

An incoming call from a SIP subscriber arrives at the inbound SIP interface using RADIUS (if this protocol is used), the possibility of further routing of the call is determined. The default routing context is defined from the properties of the SIP trunk, and call routing begins in this context. Next, routing works out exactly the same as in the case of a call from a SIP trunk. An incoming call from a Megaco subscriber goes to the inbound Megaco interface. The default routing context is defined from the properties of the SIP trunk, and call routing begins in this context. Next, routing works out exactly the same as in the case of a call from a SIP trunk.

Recommended scheme for "PBX with access to the city" routing contexts

This section describes an example of building routing contexts for a virtual PBX, which is positioned as a PBX with access to the city via a SIP trunk or via a bridge interface.

The general scheme for creating routing contexts is shown in Figure 2.

Image RemovedImage Added

Figure 2 — General scheme of routing contexts

...

The call comes from the city (SIP trunk or bridge interface) to the local subscriber. The call is sent to the city numbering plan, the properties "apri", "nai", "ni", "npi", "screening" are automatically set for subscriber A, "incoming modification" is performed. Next, the call is routed. Routing determines that the call has been received by a local subscriber. Therefore, there is a transition to the routing context, designed to modify the numbers when reaching local subscribers, if necessary. In this context, an "exit modification" is performed, after which the call is sent to the local subscriber. When accessing a local subscriber, the system searches for the subscriber of this PBX by the number of subscriber B in the city numbering plan, which has the number B set in the city numbering plan, which was received as a result of routing. If there are more than one such subscriber, then the subscriber to whom this number was installed first is selected. And the call is directed to this subscriber. If the subscriber is not found, the call is rejected.

Recommended scheme for routing contexts for a "Transit PBX"

Image RemovedImage Added

Figure 3 — Diagram of the building of routing contexts for a "Transit PBX"

...

A call from trunk #1 to trunk #2 passes in the same way.

The scheme of PBX connection to the city through a transit PBX

In this example, a situation when the PBX uses a central PBX to access the city is considered (access to the central PBX is carried out via Bridge).

Image RemovedImage Added

Figure 4 — The scheme of PBX connection to the city through a transit PBX

...

In PBX #1, the call is routed through the "Inbound bridge interface from the central domain", enters the routing context in the city numbering plan set by default, where the numbers A and B, as well as their properties in the "Urban numbering plan" are modified. Next, direct routing of the call is performed, as a result of which it is determined that subscriber B is a local subscriber of this PBX. Therefore, a transition is made to the routing context, designed to modify the numbers when reaching local subscribers, if necessary. In this context, an "outgoing modification" is performed, after which the call is sent to the local subscriber. When accessing a local subscriber, the system searches for the subscriber of this PBX by the number of subscriber B in the city numbering plan, which has the number B set in the city numbering plan, which was received as a result of routing. If there are more than one such subscribers, then the subscriber to whom this number was installed first is selected. And the call is directed to this subscriber. If the subscriber is not found, the call is rejected.

Creating and configuring routing context files 

Якорь
create_ctx create_ctx

Routing contexts are created and configured from under the Linux operating system or via web configurator, which allows viewing the current settings of routing contexts, create, delete and adjust their elements.

...

All possible options for triggering conditions, sets of operations and execution results are given in Detailed description of the routing configuration file section.

The order of creating the routing context file

...

<rule name="to_intercity">
     <conditions>
         <calling access_intercity="true"/>
         <cdpn digits="8%"/>
     </conditions>
     <actions>
         <cdpn digits="8[calling.provider]{%}"/> % Вместо [calling.provider] будет выбран номер оператора связи, прописанный в свойствах абонента
     </actions>
     <result>
         <external>
            <direction value="to_intercity"/>
         </external>
    </result>
</rule>

Configuring routing parameters via CLI 

Якорь
import_ctx import_ctx

After the routing contexts are created, the routing parameters are configured.

...

The routing management CLI commands are located under the path /domain/<DOMAIN>/routing/.

Configuring routing parameters via web configurator  

Якорь
web_ctx web_ctx

The Routing manager application is used to work with routing via the web configurator.

...

• Register a unique name that defines it;
• Create a rule trigger condition (Virtual PBX. Telephone call routing v2conditions);
• If necessary, create a set of operations to perform routing (Virtual PBX. Telephone call routing v2actions);
• Define the result of routing. The most common routing options are calls to the local subscriber <local> and calls to the external direction <external>.

...

RADIUS routing of phone calls 

Якорь
radius_routing radius_routing

It is possible to change the parameters of a passing call using commands from the RADIUS server sent in response to RADIUS-Authorization requests. The commands are transmitted in text form using the Vendor-Specific attribute with the vendor number assigned to "ELTEX Enterprise LLC" equal to 35265, and with "Eltex-AVPair" attribute name with number 1. In general, the format of the Eltex-AVPair attribute looks like the following:

...

This rule states that if the conditions match, perform external RADIUS routing on servers with master IDs (and if it is unavailable, backup). At the same time, no more than 5000ms should be spent on external routing. Based on the results of the RADIUS request, ECSS routing will continue in the context of ctx_after_radius, but with CgPN, CdPN tag changed (if these fields were changed as a result of the RADIUS request).

Syntax of a request to change the Tag parameter

The command consists of the following parts.

...

Vendor-Specific(26): Eltex(35265): Eltex-AVPair(1):CallManagement:Tag=to_nsk

Syntax of a request to modify CgPN and CdPN numbers

The command consists of a mandatory and optional parts. The mandatory part consists of the initial text identifier of the command, the identifier of the number being modified and the modification mask.

...

• $modify-mask – number modification rule (the syntax of the modification rule is described in Syntax of modification rules section);
• $numtype – (nai parameter on SSW) one of the values:
  • internationNumber, nationalNumber, subscriberNumber, unknown;
  • international, national, network-specific, subscriber, unknown;
• $plantype – (npi parameter on SSW) one of the values:
  • dataNumberingPlan, isdnTelephony, telexNumberingPlan;
  • isdn, national, private, unknown;
• $presentation – (apri parameter on SSW) one of the values:
  • addressNotAvailable, presentationAllowed, presentationRestricted;
  • allowed, restricted, not-available, spare;
• $DisplayName — name displayed on the phone's display.

...

Vendor-Specific(26): Eltex(35265): Eltex-AVPair(1): CallManagement:CgPN=+7383
Vendor-Specific(26): Eltex(35265): Eltex-AVPair(1): CallManagement:CgPN=;numtype=national
Vendor-Specific(26): Eltex(35265): Eltex-AVPair(1): CallManagement:CgPN=;presentation=restricted

Syntax of the modification rule 

Якорь
syntax_ctx syntax_ctx

The modification rule is a set of special characters that define number changes:

• '.' and '-' — special characters indicating that the digit at this position of the number is deleted, and the digits following are shifted in its place;
• 'X', 'x' — special characters indicating that the digit at this position remains unchanged (mandatory presence of a digit at this position);
• '?' — special character indicating that the digit at this position remains unchanged (optional presence of a digit at this position);
• '+' — special character, meaning that all characters between this position and the next special character (or the end of the sequence) are inserted into the number at the specified place;
• '!' — special character indicating the end of parsing, all further digits of the number are cut off;
• '$' — special character indicating the end of parsing, all further digits of the number are used unchanged;
• 0-9, D, # and * (which do not have a special '+' character in front of them) — informational characters that replace the digit in the number at this position.

Detailed description of the routing configuration file 

Якорь
detail detail

The configuration file for telephone routing is a file in XML format, which is designed in accordance with the data diagram given in the attachment:ecss_routing.xsd file. 

...

<context>
  <rule>
    <conditions>
    </conditions>
    <actions>
    </actions>
    <result>
    </result>
  </rule>
  <rule>
  </rule>
...
  <rule>
  </rule>
</context>

<context>

The basic element of the routing file that describes the parameters of the routing context.

...

In this case, the bridge must come from the domain <DOMAIN_NAME> and use the numbering plan
<NUMBER_NAME>.

<rule>

The <rule> element describes the routing rule.
The structure of the routing rule has the following form:

...

• RuleName — the name of the routing rule. A string that must be unique within the routing context is output during routing tracing;
• <conditions> — mandatory element describing the conditions for triggering the routing rule;
• <actions> — optional element describing a set of operations that are applied to the call parameters when the routing rule is triggered;
• <result> — mandatory element describing the result of processing the routing rule.

<conditions> 

Якорь
conditions conditions

The <conditions> element describes a set of conditions, the fulfillment of which leads to the fulfillment of the rule.

...

Each of the above elements within <conditions> is optional and can be used no more than once.
An empty set of criteria indicates that there are no restrictions.

<calling>

Caller's access parameters.

...

The attributes of the <calling> element are optional, but at least one attribute must be specified.
The order of specifying attributes is arbitrary.

<called>

The access parameters of the called subscriber (only for Russia).

<cdpn>

The number parameters of the called subscriber.

<cdpn digits="Digits"
      nai="Nai"
      incomplete="boolean"
      inni="Inni"
      npi="Npi"
      ni="Ni"
      in_list="listName"/>

where:

• digits — the mask of digits of the number of the called subscriber.
• nai — number type (NatureOfAddressInformation), takes the values: subscriberNumber, unknown, nationalNumber, internationonnumber;
• incomplete — the attribute of the full number, takes the values:
  • false — the number is complete,
  • true — the number is incomplete;
• inni — indicator of an intranet number (InternalNetworkNumberIndicator), takes the values:
  • routingToInternalNumberAllowed — routing to an internal number is allowed,
  • routingToInternalNumberNotAllowed — routing to an internal number is not allowed;
• npi — numbering plan code (NumberingPlanIndicator), takes the values: isdnTelephony, dataNumberingPlan, telexNumberingPlan, reserved1 (code 5), reserved2 (code 6), reserved3 (code 7);
• ni — number attribute (NumberIndicator), takes the values:
  • private — private network;
  • local — local network;
  • zone — zone network;
  • intercity — intercity network;
  • international — international network;
  • emergency — special services.
• in_list — name of the list for checking numbers for inclusion. The list can be generated in the Monitoring groups web configurator application or by CLI commands (/domain/<DOMAIN>/lists/). The list type must be default. 

<cgpn>

The number parameters of the calling subscriber.

<cgpn digits="Digits"
      nai="Nai"
      incomplete="boolean"
      npi="Npi"
      apri="Apri"
      screening="Screening"
      ni="Ni"
      in_list="listName"/>

where:

• digits — the mask of the digits of the caller's number;
• nai — number type (NatureOfAddressInformation), takes the values: subscriberNumber, unknown, nationalNumber, internationonnumber;
• incomplete — the attribute of the full number, takes the values:
  • false — the number is complete,
  • true — the number is incomplete;
• npi — numbering plan code (NumberingPlanIndicator), takes the values: isdnTelephony, dataNumberingPlan, telexNumberingPlan, reserved1 (code 5), reserved2 (code 6), reserved3 (code 7);
• apri — indicator for limiting the provision of the caller's number (AddressPresentationRestrictionIndicator):
  • presentationRestricted — prohibition,
  • presentationAllowed — resolution,
  • addressNotAvailable — unavailability of the number;
• screening — the indicator for monitoring the caller's number, takes the values:
  • userProvidedNotVerified — provided by the user, not verified;
  • userProvidedVerifiedAndPassed — provided by the user, verification passed;
  • userProvidedVerifiedAndFailed — provided by the user, verification failed;
  • networkProvided — provided by the network.
• ni — number attribute (NumberIndicator), takes the values:
  • private — private network;
  • local — local network;
  • zone — zone network;
  • intercity — intercity network;
  • international — international network;
  • emergency — special services.
• in_list — name of the list for checking numbers for occurrence. The list can be generated in the Monitoring groups web configurator application or by CLI commands (/domain/<DOMAIN>/lists/). The list type must be default.

<rgn>

Parameters of the number that performed the redirection.

...

<time>

Time of day, set as: HH:MM-HH:MM

...

• value — mask of the time of day.

<date>

Date, set as: DD1.MM1.YYYY1-DD2.MM2.YYYY2

...

<date value="DateMask"/>

where:

• value — date mask. 

<weekday>

The day of the week mask sets a set of days of the week.
The format of the description of the mask of the days of the week: "DN1,DN2,...,DNX"

...

• value — mask of the day of the week;
• day_types — comma-separated types of days of the week. Possible values:
  • day-off — day off;
  • half-holiday — pre-holiday day;
  • holiday — a festive day;
  • work — working day.

<timetable>

Timetable — the name of the schedule that will be used for checking during routing.

...

<timetable value="working_time" />

<tag>

A special parameter that can be set for calling during routing.
The parameter is valid only at the routing stage, is set in the routing rule and is subsequently used to change the routing logic.

...

• value — string, the value of the "tag" field for the call is checked for a complete match. The default value is "default".

<final>

Indicates the final routing. The dialing of number B is completed (the timer for the end of dialing is triggered) or the number is complete (it came in the "enblock" mode).

...

• value — indicates the final routing, takes the value:
  • true — the number is incomplete;
  • false — additional dialing is possible by number B.

<cause>

The reason for disconnecting the previous call attempt.
The mechanism allows using the "Cause" routing mode. When a call from subscriber A to subscriber B has been completed with a certain termination code without a conversation phase, then re-routing is performed, the reason for disconnection is specified as one of the parameters.
If the "Cause" routing rules are correctly configured in the system, it is possible to transfer such calls to various types of autoinformers (forwarding to autoinformers with messages such as "the subscriber is temporarily unavailable", "the line is overloaded", "the subscriber does not exist" and others).

...

• cause — the reason of disconnection.

<ocdpn>

Parameters of the original number to which the call was made.

...

• digits — mask of digits of the number of the called subscriber.
• nai — number type (NatureOfAddressInformation), takes the values: subscriberNumber, unknown, nationalNumber, internationonnumber;
• incomplete — attribute of the full number, takes the values:
• false — number is complete,
• true — number is incomplete;
• npi — numbering plan code (NumberingPlanIndicator), takes the values: isdnTelephony, dataNumberingPlan, telexNumberingPlan, reserved1 (code 5), reserved2 (code 6), reserved3 (code 7);
• apri — indicator for limiting the provision of the caller's number (AddressPresentationRestrictionIndicator):
  • presentationRestricted — prohibition,
  • presentationAllowed — resolution,
  • addressNotAvailable — unavailability of the number;
• ni — number attribute (NumberIndicator), takes the values:
  • private — private network;
  • local — local network;
  • zone — zone network;
  • intercity — intercity network;
  • international — international network;
  • emergency — special services.
• empty — whether the OriginalCalledNumber parameter is present in the call signaling (If this parameter is set, all other parameters (digits, nai, incompele, npi, apri, ni) should not be set
  • false — RedirectingNumber is not present in the alarm;
  • true — OriginalCalledNumber is present;
• category — subscriber's category, can take a string or numeric value according to Table 1.

in_list — name of the list for checking numbers for occurrence. The list can be generated in the Monitoring groups web configurator application or by CLI commands. The list type must be default. 

<actions> 

Якорь
actions actions

The <actions> element describes a set of actions performed when the rule is triggered.

...

Actions are indicated in the order in which they are performed. All actions are optional.

<set_options>

A low-level operation that can be used to modify special call properties.
It is used to transfer optional parameters from routing to the kernel, to the variables of the IVR script.
In order to define an IVR script variable, the key field must start with ivr_variable.
For example, to set an IVR variable named CARD_PLATFORM_TO_NUMBER, the key field must be equal to ivr_variable:CARD_PLATFORM_TO_NUMBER.

...

<actions>
 <set_options>
  <option key="ivr_variable:card_platform_to_number" value="{def}"/>
 </set_options>
</actions>

<cgpn>

Modification of the called subscriber number parameters.

<cgpn digits="Digits"
      nai="Nai"
      incomplete="boolean"
      npi="Npi"
      apri="Apri"
      screening="Screening"
      ni="Ni"/>

where:

• digits — mask of modification of digits of the number or new digits of the number.

The description of the parameters "nai", "incomplete", "npi", "apri", "screening", "ni" is similar to the description of the parameters of the element "cgpn" of the section "conditions".

<cdpn>

Modification of the Subscriber B number parameters.

...

• digits is the mask of the modification of the digits of the number or the new digits of the number, the other parameters are similar to the parameters of the "cdpn" element of the "conditions" section.

<rgn>

Modification of the parameters of the number that performed the forwarding.

...

• digits is the mask of the modification of the digits of the number or the new digits of the number, the other parameters are similar to the parameters of the "cdpn" element of the "conditions" section.

<restore_cgpn>

Restoring the original values of the caller's number parameters that were present when entering the routing context.

This element has no attributes.

<restore_rgn>

Restoring the original parameter values of the number that performed the redirection, which were when entering the routing context.

This element has no attributes.

<empty_rgn>

Remove the RedirectingNumber parameter from the alarm.

This element has no attributes.

<restore_cdpn>

Restoring the original values of the parameters of the number of the called subscriber, which were when entering the routing context.

This element has no attributes.

<calling>

Modification of the caller's access parameters.

...

• %CITY% — city of subscriber A, based on Register of the Russian numbering plan (only for Russia);
• %REGION% — subscriber's region A, based on Register of the Russian numbering plan (only for Russia);
• %OPERATOR% — operator of subscriber A, based on Register of the Russian numbering plan (only for Russia).

<called>

Modification of the caller's access parameters (only for Russia).

<final value="true">

Setting the final routing flag. The dialing of number B is completed (the timer for the end of dialing is triggered) or the number is complete (it came in the "enblock" mode).

<alarm>

Adding an emergency event to ECSS-10.

...

• severity — the severity level of the emergency event, possible values: warning, minor, major, critical, indeterminate, cleared;
• value — string description of this emergency event. The description string supports the following set of macros:
  • %TAG% — values of the tag field;
  • %CDPN.NAI% — nai value for the called subscriber;
  • %CDPN.NI % — the ni value for the called subscriber;
  • %CDPN.INCOMPLETE% — incpomlete value for the called subscriber;
  • %CDPN.INNI% — inni value for the called subscriber;
  • %CDPN.NPI% — npi value for the called subscriber;
  • %CDPN.DIGITS% — number for the called subscriber;
  • %CGPN.NAI% — nai value for the caller;
  • %CGPN.NI % — the ni value for the caller;
  • %CGPN.INCOMPLETE% — incpomlete value for the caller;
  • %CGPN.NPI% — npi value for the caller;
  • %CGPN.APRI% — value of apri for the caller;
  • %CGPN.SCREENING% — value of screening for the caller;
  • %CGPN.DIGITS% — caller's number;
  • %DOMAIN% — domain within which this call was routed;
  • %ISFINAL% — value of the isFinal parameter;
  • %CONTEXTNAME% — name of the routing context;
  • %IFACEA% — subscriber A interface;
  • %DATETIME% — time at which the routing was performed.

<log>

Create an entry in the system log.

...

• severity — an indicator of the criticality of writing to the system log, possible values: error, warning, info;
• value — the text of the entry in the system log. The description string supports the following set of macros:
  • %TAG% — values of the tag field;
  • %CDPN.NAI% — nai value for the called subscriber;
  • %CDPN.NI % — ni value for the called subscriber;
  • %CDPN.INCOMPLETE% — incpomlete value for the called subscriber;
  • %CDPN.INNI% — inni value for the called subscriber;
  • %CDPN.NPI% — npi value for the called subscriber;
  • %CDPN.DIGITS% — number for the called subscriber;
  • %CGPN.NAI% — nai value for the caller;
  • %CGPN.NI % — ni value for the caller;
  • %CGPN.INCOMPLETE% — incpomlete value for the caller;
  • %CGPN.NPI% — npi value for the caller;
  • %CGPN.APRI% — value of apri for the caller;
  • %CGPN.SCREENING% — value of screening for the caller;
  • %CGPN.DIGITS% — caller's number;
  • %DOMAIN% — domain within which this call was routed;
  • %ISFINAL% — value of the isFinal parameter;
  • %CONTEXTNAME% — name of the routing context;
  • %IFACEA% — subscriber A interface;
  • %DATETIME% — time at which the routing was performed.

<cause>

In order to be able to set the causes that need to be routed by goats, a section "Reasons for re-routing" should be added in the "Action" block. In this section, add three input fields:

...

<rule name="rule1">
  <actions>
    <cause acp="normal, bPtyBusy" isup="16,17,18" sip="401, 400"/>
  </actions>
</rule>

<external_routing>

Calling an external routing service (currently only external Radius routing is supported).

...

<actions>
 <external_routing id="master;backup" service="radius_route_service" timeout="1000"/>
</actions>

<ocdpn>

The operation of parameters modification of the original number to which the call was made.

...

• digits — mask of modification of digits of the number or new digits of the number, a detailed description is given in Number Digit Mask section;
• nai — number type (NatureOfAddressInformation), takes the values: subscriberNumber, unknown, nationalNumber, internationonnumber;
• incomplete — attribute of the full number, takes the values:
• false — number is complete,
• true — number is incomplete;
• npi — numbering plan code (NumberingPlanIndicator), takes the values: isdnTelephony, dataNumberingPlan, telexNumberingPlan, reserved1 (code 5), reserved2 (code 6), reserved3 (code 7);
• apri — indicator for limiting the provision of the caller's number (AddressPresentationRestrictionIndicator):
  • presentationRestricted — prohibition,
  • presentationAllowed — resolution,
  • addressNotAvailable — unavailability of the number;
• ni — number attribute (NumberIndicator), takes the values:
  • private — private network;
  • local — local network;
  • zone — zone network;
  • intercity — intercity network;
  • international — international network;
  • emergency — special services.
• empty — whether the OriginalCalledNumber parameter is present in the call signaling (If this parameter is set, all other parameters (digits, nai, incompele, npi, apri, ni) should not be set
  • false — RedirectingNumber is not present in the alarm;
  • true — OriginalCalledNumber is present;
• category — subscriber's category, can take a string or numeric value according to Table 1.

<restore_ocdpn>

Restoring the original parameter values of the original number to which the call was made, which were when entering the routing context;
This element has no attributes.

<empty_ocdpn>

Remove the OriginalCalledNumber parameter from the alarm.
This element has no attributes.

<result> 

Якорь
result result

This mandatory <result> element describes the result of processing the routing rule.

...

• Result — the result of the rule execution, takes the values: local; external; incomplete; no_route; continue.

<local>

A local domain subscriber was found.
The number is complete, the subscriber is found, the router searches for the subscriber's interface by its number and stops routing, returning the found data for subscribers A and B, interfaces A and B.

...

• tag is a string tag used in further processing of a call on routing. The tag must be set, because if it is not set and not processed in routing, this will lead to routing looping.

<ivr>

The direction of exit from the domain to the ivr service (related to this domain) is found; the router stops routing, returning the found data on subscriber A, interfaces A and B.

...

• script — the name of the ivr script that will be executed when exiting according to this rule.

<external>

The domain exit interface is found (trunk to another domain, trunk to another station, etc.), the router stops routing, returning the found data for subscribers A and B, interfaces A and B.

...

<external>
              <trunk value="ems1" weight="50" max_load="60%"/>
              <trunk value="ems2" weight="50"/>
</external>

<direction>

The direction of exit from the domain to the direction is found; the router stops routing, returning the found data on subscriber A, interface A and direction.

...

<incomplete>

The number is incomplete. Routing ends with a sign that an incomplete number has been dialed, the kernel continues to accumulate digits of the number.

...

<no_route>

Routing error. Routing ends with a sign that an incorrect number has been dialed.

...

• isup_cause — optional parameter, number, isup reasons to be used in the rel message.

<continue>

Continue routing in the current or in another context of this virtual PBX (domain).

...

• context — name of the context in which the routing will continue. If not specified, then continue in the same context;
• tag — optional field, the ability to set the value of the "tag" parameter, which can then be used in conditions of triggering routing rules during subsequent analysis, makes it possible to do some kind of conditional parametric routing.

<next>

Continue routing in the current context from the next rule. If the conditions are met, a set of actions from the <actions> element will be applied.

...

• tag — optional field, the ability to set the value of the "tag" parameter, which can then be used in conditions of triggering routing rules during subsequent analysis, makes it possible to do some kind of conditional parametric routing.

Time mask 

Якорь
time_mask time_mask

<conditions>
  <time value="09:00 - 18:00"/>
</conditions> 

<conditions>
  <time value="*:20 - *:30"/>
</conditions> 

Date mask 

Якорь
date_mask date_mask

<conditions>
  <date value="01.01.* - 31.01.*"/>
</conditions>

<conditions>
 <date value="10.*.* - 20.*.*"/>
</conditions>

<conditions>
  <date value="13.12.2011 - 13.12.2011"/>
</conditions> 

Weekday mask 

Якорь
weekday_mask weekday_mask

<weekday value="WeekdayMask" day_types="DayTypes" />

<conditions>
  <weekday value="1,2,3,4,5" day_types="work" /> 
</conditions> 

<conditions>
  <weekday value="6,7" day_types="day-off,holiday"/>
</conditions>

Number digit mask 

Якорь
number_mask number_mask

The number digits mask in the field of conditions for triggering the rules. Provides a convenient and flexible syntax for describing various numbers.
Regular expressions are not used intentionally, because this significantly increases the qualification threshold of an engineer, which is necessary to use the mechanism.

...

• Comparing parameters with each other:

  Блок кода
  <conditions> <cdpn digits="[cgpn{1,2}]??"/> <cgpn digits="[cdpn{1,2}]??"/> </conditions>

  
  

• Using a parameter that does not exist:

  Блок кода
  <conditions> <cgpn digits="[cdpn{1,2}]??"/> </conditions>

  
  

• Going beyond the boundaries of the compared parameter:

  Блок кода
  <conditions> <cdpn digits="????"/> <cgpn digits="[cdpn{5,6}]??"/> </conditions>

  
  

Modification of the digits of the number 

Якорь
modify_number modify_number

In the call parameter modification actions, one of the main elements for correction is to change the digits of the subscriber number A or B.
There are different approaches to the way of describing the syntax of such modification: modification on templates, regular expressions, etc.

...

<conditions>
  <cgpn digits="???????" ni="local"/>
  <cdpn digits="8%"/>
</conditions>
<actions>
  <cgpn digits="8383{1,2,3,4,5,6,7}" ni="intercity" nai="nationalNumber"/>
</actions>

Multiple routing

With multiple routing, the result can be routing either to a local subscriber or to a trunk. To do this, add the continue section inside the local section.

Example 1

There are subscribers with three-digit numbers in the 7xx format. Some of these subscribers are on a third-party station, to which there is a trunk named PANASONIC_TRUNK.

...

  <context xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="ecss_routing.xsd" name="ctx_city_local">
    <rule name="panasonic_users">
      <conditions>
        <cdpn digits="7??"/>
        <tag value="not_local_user"/>
      </conditions>
      <result>
        <external>
          <trunk value="PANASONIC_TRUNK"/>
        </external>
      </result>
    </rule>
    <rule name="local">
      <conditions>
        <cdpn digits="7??"/>
      </conditions>
      <result>
        <local>
          <continue tag="not_local_user">
        </local>
      </result>
    </rule>

Example 2

There are subscribers with three-digit numbers in the 7xx format. If the call goes to a number that does not exist, then the phrase "The subscriber with this number does not exist in our company. The call is transferred to the secretary.", and the call is transferred to the secretary. To do this, an IVR script is created with the name to_secretary (script ID: e5a8909590717068), and the following routing context is written:

  <context xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:noNamespaceSchemaLocation="ecss_routing.xsd" name="ctx_city_local">
    <rule name="panasonic_users">
      <conditions>
        <cdpn digits="7??"/>
        <tag value="not_local_user"/>
      </conditions>
      <result>
        <ivr script="e5a8909590717068"/>
      </result>
    </rule>
    <rule name="local">
      <conditions>
        <cdpn digits="7??"/>
      </conditions>
      <result>
        <local>
          <continue tag="not_local_user">
        </local>
      </result>
    </rule>

Things to remember

When creating routing contexts, it is necessary to pay attention to the fact that the call is successfully routed both in enblock mode and in overlap mode.

...

Therefore, remember that depending on the nuances in the description of the context, the same set in two different modes can lead to different results.

Re-routing using cause ISUP, ACP, SIP

Description of the re-routing mechanism

Sometimes it is required that a call that could not be established with a specific reason is sent to another direction or an autoinformer. For this purpose, the "Cause" routing mechanism is used. For example: there is a call from number A to number B. In the context of routing, there is a direction to subscriber B, while the "Reasons for re-routing" parameter is defined in the "actions" block, it means that if the call to subscriber B ends with one of the listed reasons, re-routing from A to number B will be performed, indicating the current reason for the end of the call. In order to use the specified reasons, in the context of routing, in the "conditions" section, the "reasons" parameter can be specified in the "additional" section. It checks whether at least one of the specified reasons coincided with the reason for disconnecting the call transmitted to the routing. If yes, then this rule will work and allow redirecting the call to another direction.

Re-routing

The mechanism allows using the "Cause" routing mode. When a call from subscriber A to subscriber B has been completed with a certain termination code without a conversation phase, then re-routing is performed, the reason for disconnection is specified as one of the parameters.
In case of simultaneous indication of several reasons for disconnection, the rule will work if at least one of the reasons coincides.

...

• ACPCauses — comma-separated list of ACP call disconnection reasons;
• ISUPCauses — comma-separated list of the ISUP reason for disconnecting the call;
• SIPCauses — comma-separated list of SIP call disconnection reasons.

The reason for disconnecting the previous call attempt in the conditions block

The mechanism allows using the "Cause" routing mode. When a call from subscriber A to subscriber B has been completed with a certain termination code without a conversation phase, then re-routing is performed, the reason for disconnection is specified as one of the parameters.

...

/domain/refactor/properties/set alternate_route_sip_causes add 404/user

Reasons for re-routing in the Action block

The reason(s) for disconnecting this call, for which it is necessary to iterate through the routes.
The mechanism allows using the "Cause" routing mode. When a call from subscriber A to subscriber B was completed with one of the reasons specified in <cause>, the call will be re-routed, but the routing will specify the reasons with which the current call ended (routing by "Cause" works only for calls that ended before the conversation/alerting phase). How these rules are applied in the context of routing, see here: <actions>.

...

RADIUS routing of phone calls

Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): xpgk-route-retries=<$ROUTE_RETRIES>
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): ecss-routing-cause-isup=<$ROUTE_CAUSE_ISUP>
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): ecss-routing-cause-sip=<$ROUTE_CAUSE_SIP>
Vendor-Specific(26): Cisco(9): Cisco-AVPair(1): ecss-routing-cause-acp=<$ROUTE_CAUSE_ACP>

...