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.

An incoming call from IP trunk or from a subscriber comes at the incoming interface. By means of the RADIUS protocol (if used), the possibility of further call routing is determined. Then, in a certain routing context of the virtual PBX, which corresponds to the input interface, call processing is performed. The conditions of call selection are checked (analysis of the numbers of the called, caller, day of the week, time of day) for compliance with one of the rules of the routing context.
If necessary, the call input data is modified and routed according to the specified parameters — to the subscriber, to the external direction, to another routing context:

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

Figure 1 — General scheme of telephone call flow

An incoming call from the IP channel arrives at the inbound interface (SIP trunk). The default routing context is defined from the properties of the SIP trunk, and call routing begins in this context. When entering the routing context, its numbering plan is checked. If it differs from the numbering plan of the outgoing context, then the properties specified in the numbering plan of the new context are set for subscriber A. Next, call routing is performed directly, including modifications of the numbers and properties of subscribers A and B
transitions between routing contexts (within the same routing context) with a possible change of numbering plans.

Routing continues until an outbound route is found, or it is determined that there is no route, or the number of transitions from one rule to another does not exceed 1000 iterations. When accessing the local ECSS-10 subscriber, the properties specified in the numbering plan of the routing context in which the route was found are applied to subscriber B. After that, the call is sent to the SIP/Megaco subscriber.

When entering a set of outbound trunks, if one of the trunks is not available, the call will be directed to the next trunk in the list. Such a search will be performed as long as there is at least one trunk to which there was no attempt to send a call. When entering to the outgoing direction, a list of trunks entering this direction is determined, and the call is sent as a "set of outbound trunks" (described above).

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.

Figure 2 — General scheme of routing contexts

There are two numbering plans in this virtual PBX: the "internal numbering plan" and the "urban numbering plan". All calls within this PBX pass through the internal numbering plan. It is in it that the call routing is performed directly. Using the city numbering plan, subscribers are able to access the city under city numbers. All local subscribers, as well as trunks, have a default routing context in the internal numbering plan.

Examples of various combinations of a call flow according to this scheme are given:

General flow scheme

The call comes from a local SIP/Megaco subscriber and is routed to the default routing context in the private numbering plan. In this context, the numbers of subscribers A and B are brought to the internal format of the numbers by which calls are routed, the properties of these numbers are set. This phase of routing will be called "incoming modification".

Next, the call is routed to the root context of the private numbering plan for direct routing. During routing, it is not supposed to change the numbers A and B, as well as their properties, but transitions between contexts are possible. When routing has detected an outgoing direction, it goes into a special routing context, which is engaged in converting numbers and their properties to reach this direction. This phase of routing will be called "outgoing modification".
After exiting this context, there will be the numbers A, B and also their properties as side B understands them.

Calling from a local subscriber to a local subscriber

The call comes from a local SIP/Megaco subscriber. The call is routed to the private numbering plan, "incoming modification" is performed for subscribers A and B, and then the call is routed. During routing, it was determined that subscriber B is a local subscriber — a subscriber of this virtual PBX. Therefore, routing goes into a context designed to modify numbers when reaching local subscribers, if necessary. In this context, a modification is performed, after which the call is sent to the local subscriber.

Call from a local subscriber to the city

The call comes from a local SIP/Megaco subscriber. The call is routed to the private numbering plan, "incoming modification" is performed for subscribers A and B, and then the call is routed. During routing, it was determined that subscriber B is a city subscriber. Therefore, the numbering plan needs to be changed to urban by switching to one of the routing contexts in the urban numbering plan. When switching to the city numbering plan, the properties "apri", "nai", "ni", "npi", "screening" for the urban numbering plan will be automatically set for subscriber A, as well as the number of subscriber A, if he has a number for the city numbering plan. Further, routing continues in the urban numbering plan. When routing determines the direction (trunk, bridge interface) of the call, a transition will be made to the routing context to access this direction. In this routing context, an "outgoing modification" will be performed, and the call will be routed to the SIP trunk or bridge interface to the city.

Call from the city to a local subscriber

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"

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

In case of a transit virtual PBX, there is one "private numbering plan" within which all call routing is performed.

Example: the call comes from the incoming SIP trunk #1 and should be routed to trunk #2. First, the call enters the routing context for the SIP trunk set by default #1, where the numbers A, B, as well as their properties are brought to the internal numbering plan ("incoming modification"). Further, on the basis of the modified data, call routing is performed, according to the results of which a route to the outgoing direction #2 will be found. As soon as the route is found, the call goes to the "routing context for modifying numbers and their properties at the exit to direction #2" (modification at the exit). It converts subscriber numbers A, B, as well as their properties to a format that trunk #2 accepts. Next, the call goes in this direction.

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

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

PBX subscriber #1 calls the city

The call comes from a local SIP/Megaco subscriber, then it is sent to the private numbering plan, after that incoming modification is performed for subscribers A and B, and then the call is routed. During routing, it was determined that subscriber B is a city subscriber. Therefore, the numbering plan needs to be changed to urban by switching to one of the routing contexts in the urban numbering plan. When switching to the city numbering plan, the properties "apri", "nai", "ni", "npi", "screening" for the city numbering plan will be automatically set for subscriber A, as well as the number of subscriber A, if he has a number for the city numbering plan. Further, routing continues in the urban numbering plan. When routing determines the direction of the call (finds the bridge interface), a transition will be made to the routing context to access this bridge interface. In this context of routing, an "outgoing modification" will be performed, within which the subscriber numbers A, B, as well as their properties will be brought to a form understandable in the central domain. Next, the call is routed to the found bridge interface, passing through which it enters the central domain through the "Inbound bridge interface of PBX #1". In the central domain, the call is routed to the default routing context for this bridge interface, where the numbers A, B, as well as their properties can be converted to the internal numbering plan. Also in this context, a check for the correctness of the numbers A, B that came from the bridge interface can be added. Further, on the basis of the modified data, call routing is performed, according to the results of which a route to the outgoing direction #2 will be found. After that, the call goes to the "routing context for modifying numbers and their properties at the exit to the city", where the modification at the exit is performed. The call comes in the direction to the city.

A call is received from the city to the PBX subscriber #1

A call comes to the central domain from the "inbound SIP trunk (call from the city)", gets into the default routing context in the internal numbering plan, where the numbers A and B are modified, as well as their properties to the internal numbering plan. Further, on the basis of the modified information, the call is routed, during which it is determined that the call goes to the PBX subscriber # 1. Routing goes into the "context for modifying numbers and their properties upon exiting to PBX #1", after which the call is sent to bridge to PBX #1.

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 

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.

When working via web configurator, creating a routing context in the Linux operating system, as described in this section, is not necessary.

If working in the CLI management console, then to create routing contexts, exit the CLI management console using the exit command.

When installing the ECSS-10 system, the default path is automatically prescribed, under which the routing contexts /var/lib/ecss/routing/ctx/src/<DOMAIN>/ will be located.

A separate file must be created for each routing context in the /var/lib/ecss/routing/ctx/src/<DOMAIN>/ folder. The description of the routing context file is performed using the XML markup language.

The routing context is described in the file by the <context> tag and contains one or more <rule> rules. The rules include a description of the trigger conditions <conditions>, a set of operations for routing <actions> and the result of the call routing <result>.

The trigger conditions <conditions> determine by which rules routing will be carried out — by the number of the caller, by the number of the called, by the day of the week and other rules.

The set of operations for routing <actions> includes modification of the numbers of the called, calling subscribers, setting the "end of dialing" flag and other operations.

The result of the call routing <result> can be routing inside the virtual PBX, routing to the oncoming PBX, incorrect routing and other options.

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

To create a routing context:

1. Create a file with an xml extension.

2. Specify the xml tag version at the beginning of the file:

<?xml version="1.0"?>

3. Create a context — opening and closing tags:

<context>
</context>

In the opening context tag, specify the parameters xmlns:xs and xs:noNamespaceSchemaLocation with the following values:

xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
xs:noNamespaceSchemaLocation="ecss_routing.xsd"

Next, specify:

• an arbitrary context name that uniquely defines it;
• the domain for which the context is being created;
• context type set to local;
• rule for creating a numbering plan, set the value:
  • auto — for contexts using the H.248/Megaco protocol;
  • none — for contexts that do not use the H.248/Megaco protocol.

Example of the context opening tag:

<context xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" 
         xs:noNamespaceSchemaLocation="ecss_routing.xsd" 
         name="some_name" 
         domain="some.domain" 
         type="local" 
         digitmap="auto">

4. Create a rule inside the context — opening and closing tags:

<rule>
</rule>

In the opening tag of the rule, specify the name of the routing context:

<rule name="to_intercity">

5. Create a rule trigger condition — opening and closing <conditions> tags inside the rule and the rule trigger condition.
The most common conditions are based on the analysis of the digits of the number of the called and the caller. To do this, the <cdpn/> and <cgpn/> tags are used with the digits="Digits" number mask parameter. Prefix part of the rule:

• "?" — any non-empty element of the number (digits 0-9 or letters A, B, C, D, E, F);
• "0"-"9" — digits from 0 to 9;
• "A"-"D" — letters A, B, C, D;
• "E" — symbol *;
• "F" — symbol #;
• "( )" is a range or enumeration. The range is indicated by "-", enumeration by ",". For example, (1-6) is a range, (1,3,9) is an enumeration;
• "%" — 0 or several elements of the number.

<conditions>
 <cdpn/>
 <cgpn/>
 <calling/>
 <time/>
 <date/>
 <weekday/>
 <tag/>
 <final/>
 <cause/>
</conditions>

6. If necessary to create a set of operations to perform routing, specify the opening and closing <actions> tags inside the rule and a set of operations to perform routing.

The most common operations are based on the modification of the digits of the number of the called and the caller. The <cdpn/> and <cgpn/> tags are used for this.

<actions>
 <set_options/>
 <cgpn/>
 <cdpn/>
 <restore_cgpn/>
 <restore_cdpn/>
 <calling/>
 <final/>
</actions> 

7) To determine the result of the call routing, create the opening and closing <result> tags inside the rule and describe the routing results.

The most common routing options are calls to the local subscriber <local> and calls to the external direction <external>. When calling to an external direction, a <direction> tag is created, which specifies the name of the interface for routing the call.

<result>
<local/>
<external>
<direction/>
</external>
<no_route/>
<continue/>
<incomplete/>
</result>

Example of a routing context file

<context xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" 
         xs:noNamespaceSchemaLocation="ecss_routing.xsd" 
         name="ctx_city_local" 
         domain="d.city" 
         type="local" 
         digitmap="auto">
  <rule name="to_intercity">
    <conditions>
      <cdpn digits="8%"/>
      <cgpn digits="%"/>
    </conditions>
    <actions>
      <cdpn digits="{%}" nai="nationalNumber"/>
      <cgpn digits="383{%}"/>
    </actions>
    <result>
      <continue context="ctx_intercity"/>
    </result>
  </rule>
  <rule name="local_subscribers1">
    <conditions>
      <cdpn digits="332???"/>
    </conditions>
    <result>
      <local/>
    </result>
  </rule>
  <rule name="local_subscribers2">
    <conditions>
      <cdpn digits="77???"/>
    </conditions>
    <result>
      <local/>
    </result>
  </rule>
  <rule name="external_subscribers">
    <conditions>
      <time value="9:00 - 18:00"/>
      <date value="*.*.* - *.*.*"/>
      <weekday value="1,2,3,4,5"/>
      <cdpn digits="200??"/>
    </conditions>
    <result>
      <external>
        <direction value="port_sipt1"/>
        <direction value="port_sipt2"/>
      </external>
    </result>
  </rule>
</context>

Example of choosing a long-distance/international communication operator in the context of routing

The definition of a pre-installed long-distance/international operator for a subscriber can be performed through prefixing in accordance with the properties of subscribers. In this case, a pre-installed telecom operator can be selected for each of the subscribers.

For example, a subscriber dials 84951234567. It is necessary to replace the number in accordance with the specified provider code. To do this, use the [calling.provider] parameter assigned in the set of operations to perform routing <actions>.
If the provider's code is defined in the subscriber's properties (the subscriber's properties are configured with the command /domain/<DOMAIN>/alias/ - alias management commands), for example provider = 1501, then as a result, the number 815014951234567 will be dialed on a long-distance call station.

Example of a routing rule using subscriber properties. And when modifying numbers:

<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 

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

If the system configuration will be performed via the CLI command line interface, connect to the command console under the admin user.

Command to connect to the console:

ssh admin@localhost -p 8023

Next, import the created routing contexts into the system with the command:

/domain/<DOMAIN>/routing/import <NODE> <FILE>

context has been successfully imported

Imported contexts can be viewed with the command:

/domain/<DOMAIN>/routing/show <FILE>

If necessary, the routing context can be removed from the virtual PBX:

/domain/<DOMAIN>/routing/delete <FILE>

where:

• <DOMAIN> — name of the virtual PBX;
• <NODE> — name of the node on which the routing contexts are created;
• <FILE> — the name of the file with the routing context to be imported.

Call Tracing

Call tracing is used to monitor the correctness of the routing process for certain calls and allows displaying routing steps indicating transitions between routing contexts.

/domain/<DOMAIN>/routing/trace iface=<INTERFACE> cdpn.<PARAM>=value [<OPT1>=<VALUE1> [ ... [<OPTN>=<VALUEN>]]]

where:

• IFACE — the caller's interface;
• CDPN. — parameters of the called subscriber (cdpn.digits, cdpn.incomplete, cdpn.inni, cdpn.nai, cdpn.ni , cdpn.npi);
• OPT1.N — optional parameters — a set of input data about the telephone connection being established.

As a result of executing the command for the call input data (subscriber A interface, subscriber A context, time of day, day of the week, subscriber A number, subscriber B number), the following data will be received at the output: subscriber A interface, subscriber A domain, subscriber A context, subscriber A number (possibly modified), subscriber number B (possibly modified), subscriber interface B.

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

Configuring routing parameters via web configurator  

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

To create a routing context file via the web configurator:

1. Create a routing context in a specific virtual PBX (domain); 
2. Write an arbitrary unique name of the routing context;
3. Select the type of routing context: empty, for services, default context;
4. Create a rule in a given routing context:

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

5. Save the routing context rule;
6. Change the routing context. Changes will be made to the system.

Files with routing contexts can be created and configured from under the Linux operating system. Using the web configurator, import the created routing contexts into the system with the import command.

To ensure that the current routing contexts are always stored on the ECSS-10 server, after creating/modifying the routing context file through the web configurator, export the file to the ECSS-10 system server.

For this:

1. When exporting files via the web configurator, the files are saved on the local PC, from which the files need to be copied to the /var/lib/ecss/routing/ctx/src/<DOMAIN>/ directory on the ECSS-10 server.
2. To export the routing context file via the CLI, connect to the command console under the admin user.

Command to connect to the console:

ssh admin@localhost -p 8023

To upload the routing context file to the ECSS-10 system server, use the command:

/domain/<DOMAIN>/routing/export <NODE> <CONTEXT_NAME>

where:

• <DOMAIN> — name of the virtual PBX;
• <NODE> — name of the node on which the routing contexts are created;
• <CONTEXT_NAME> — name of the routing context.

As a result of executing the command, the routing context file created/modified via the web configurator will be saved on the ECSS-10 system server with a new name. The file name will indicate the time of export.

RADIUS routing of phone calls 

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:

Vendor-Specific(26): Eltex(35265): Eltex-AVPair(1):<$COMMAND-STRING>

By passing various commands in the $COMMAND-STRING, it is possible to control the following parameters: modification of CgPN, CdPN numbers, as well as the tag routing parameter.

For CgPN numbers, in addition to the value of the number itself, parameters such as the following can be changed:

• numtype – CgPN number type;
• plantype – type of CgPN numbering plan;
• presentation – the value of the presentation CgPN field.

For CdPN numbers, in addition to the value of the number itself, parameters such as the following can be changed:

• numtype – CdPN number type;
• plantype – CdPN numbering plan type.

In order to call external routing on ECSS-10 in the context of routing, write a rule like the following:

<rule name="to_RADIUS_routing">
   <conditions>
     ...
   </conditions>
   <actions>
         <external_routing id="master;backup" service="radius_route_service" timeout="5000"/>
   </actions>
   <result>
      <continue context="ctx_after_radius"/>
   </result>
</rule>

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.

• "CallManagement:" — a text identifier that determines that this attribute contains a command to control the call;
• "Tag=" — ID of the command, indicating that it is necessary to set the tag parameter.

The values for the Tag parameter can be any string, which can then be used on routing within the softswitch.

In general, the format of the command looks like the following:

CallManagement:Tag=<$tag>

where:

• «CallManagement:Tag=<$tag>;" — setting the tag parameter to <$tag> value.

Example
Set the value of the tag parameter to_nsk. To do this, it is enough to pass an attribute with the following value in the Access-Accept response from the RADIUS server:

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.

• "CallManagement:" — text identifier that determines that this attribute contains a command to control the call;
• "CgPN=", "CdPN=" — number identifiers, indicate which number to apply the modification to;
• "Modification mask" — rule for modifying the digits of a number (it may be empty).

An optional part can consist of either one parameter or several parameters separated by a semicolon. The mandatory and optional parts are also separated by a semicolon if there is an optional part of the command.

Possible parameters for the optional part:

• numtype;
• plantype;
• presentation.

In general, the command format looks like this (for CGPN):

CallManagement:CgPN=<$modifymask>;numtype=<$numtype>;plantype=<$plantype>;presentation=<$presentation>;displayName=<$displayName>

where:

• "CallManagement:CgPN=<$modify-mask>;" — mandatory part,
• «numtype=<$numtype>;plantype=<$plantype>;presentation=<$presentation>»; displayName=<$DisplayName> is an optional part.

In general, the command format looks like the following (for CDPN):

CallManagement:CdPN=<$modifymask>;numtype=<$numtype>;plantype=<$plantype>

where:

• "CallManagement:CgPN=<$modify-mask>;" — mandatory part,
• «numtype=<$numtype>;plantype=<$plantype>»;displayName=<$DisplayName> — optional part.

The parameters can be set in two variants — either "common designation" or in accordance with the internal names of SSW. The values of the parameters used in the commands are shown below:

• $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.

ECSS-10 allows passing the parameters of the number modification command in several attributes. Thus, a set of commands:

«CallManagement:CgPN=<$modify-mask>»

«CallManagement:CgPN=;numtype=<$numtype>»

«CallManagement:CgPN=;presentation=<$presentation>»

«CallManagement:CgPN=;displayName=<$displayName>»

equivalent to one command:

«CallManagement:CgPN=<$modify-mask>;numtype=<$numtype>;presentation=<$presentation>»

Example

Add the +7383 prefix to the CgPN number, change its number type to national and set presentation restricted. To do this, it is enough to pass an attribute with the following value in the Access-Accept response from the RADIUS server:

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

Which is also equivalent to three attributes with values:

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 

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 

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. 

The current file with the description of the data diagram is located on the deployed system under the path /usr/lib/ecss/lib/rm_lib-x.x.x.x/priv/ecss_routing.xsd.

Each XML file is a description of one routing context (a group of rules) within a virtual PBX.

Routing context description format:

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

The structure of the <context> element has the following form:

<context name="string" domain="string" digitmap="string" np="string" description="string">
</context>

where:

• name — string with the name of the routing context, must be unique within the virtual PBX;
• domain — string with the name of the virtual PBX to which the routing context refers;
• digitmap — number mask, optional parameter, takes values:
  • digitmap string for routing context;
  • auto — digitmap is generated automatically based on the routing rules described in the context, set by default;
  • none — the "digitmap" parameter is not specified.
• np — name of the numbering plan for the current routing context (if the parameter is not specified, then by default it is equal to the default value);
• description — text description of the routing context.

Next, within the <context> tag, there is a set of tags describing routing rules between the closing and opening tags.

The analysis of the conditions for triggering the rules is performed in the order in which they are specified in the file — from top to bottom.

Numbering plans

When entering the routing context, the domain settings of the new numbering plan (apri, nai, ni, npi, screening) are applied to the subscriber, if the numbering plan in the current context differs from the numbering plan in the previous context (or at the beginning of routing). If subscriber A is a local subscriber, then the number can also change for him (if it is set in the alias property [numbers] for this numbering plan). Thus, in order to change the numbering plan, it is necessary to make a transition from the routing context in the original numbering plan to the routing context in the new numbering plan (this transition is performed in the result section using the <continue /> tag).
If routing ends in a numbering plan other than the default one (with the name "default"), with the result <local />, then routing looks at who the cdpn number is assigned to in the numbering plan and follows one of the following paths:

1. the number is assigned to the alias (list of aliases) — in this case, routing ends with the choice of the master alias;
2. the number is assigned to bridge — in this case, direct the call to bridge;
3. the number is not assigned to anyone — in this case, try to find a local alias with number B. If it is located, make a call to it; otherwise, no_route.

The commands for managing numbering plans are located along the /domain/<DOMAIN NAME>/np/... path. To set a number for a local subscriber in a certain numbering plan, use the command:

/domain/<DOMAIN_NAME>/np/numbers/bind <NUMBERING_PLAN_NAME> <NUMBER_IN_NUMBERING_PLAN> --alias <OWNER_NAME> <GROUP_NAME> <INTERFACE_NAME> <LOCAL_NUMBER> [--master | --passive]
  --master — if a call in the numbering plan comes at the <NUMBER_IN_NUMBERING_PLAN> number, then it will be redirected to this alias;

To set a number for a bridge in a certain numbering plan, the following command can be used:

/domain/<DOMAIN_NAME>/np/numbers/bind <NUMBERING_PLAN_NAME> <NUMBER_IN_NUMBERING_PLAN> --bridge <BRIDGE_NAME>

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:

<rule name="RuleName">
    <conditions>
    </conditions>
    <actions>
    </actions>
    <result>
    </result>
 </rule>

where:

• 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> 

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

The description of the <conditions> element has the following form:

<conditions>
  <calling/>
  <called>
  <cdpn/>
  <cgpn/>
  <rgn/>
  <time/>
  <date/>
  <weekday/>
  <timetable/>
  <tag/>
  <final/>
  <cause/>
  <ocdpn>
</conditions>

where:

• calling — field for comparing the access parameters of the caller;
• called — field for comparing the access parameters of the called subscriber;
• cdpn — field of comparison of the number of the called subscriber (number B and its parameters);
• cdpn — field of comparison of the number of the called subscriber (number B and its parameters);
• rgn — field of comparison of the callee's forwarding number (number B, before forwarding to C);
• time — time of day;
• date — day of the year;
• weekday — day of the week;
• timetable — the name of the schedule that will be used for checking during routing;
• tag — secondary parameter for organizing multistep routing within a single context, the default value is set to "default";
• final — sign of the final routing: number B is complete or additional dialing by number B is possible;
• cause — cause for the end of the previous call attempt.

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.

<calling access_private="booleanType"
         access_local="booleanType"
         access_zone="booleanType"
         access_intercity="booleanType"
         access_international="booleanType"
         access_emergency="booleanType"
         have_access_to="atomType"
         city="stringType" 
         region="stringType" 
         operator="stringType"
         category="atomType"
         caller_id="stringType"
         display_name="stringType"
         sorm_digits="stringType"
         sorm_ni="atomType"
         interface_group="stringType"
         iface="binaryType"/>

where:

• access_private — checking the value of the access type of the called subscriber when accessing the PBX access_type/access_private.out;
• access_local — checking the value of the access type of the called subscriber when accessing the local network access_type/access_local.out;
• access_private — checking the value of the access type of the called subscriber when accessing the PBX access_type/access_private.out;
• access_private — checking the value of the access type of the called subscriber when accessing the PBX access_type/access_private.out;
• access_private — checking the value of the access type of the called subscriber when accessing the PBX access_type/access_private.out;
• access_private — checking the value of the access type of the called subscriber when accessing the PBX access_type/access_private.out;
• have_access_to — checking the access matrix of the caller for the possibility of entering the specified access group (access_matrix);
• city — the subscriber's city obtained from the database of the Russian Federation numbering plan registry (only for Russia);
• operator — the subscriber's operator obtained from the database of the Russian Federation numbering plan registry (only for Russia);
• region — the subscriber's region obtained from the database of the Russian Federation numbering plan registry (only for Russia);
• caller_id — current value of the caller ID number;
• interface_group — group of the calling interface;
• iface — name of the calling interface;
• display_name — name of the subscriber to display on the terminal (note: if the display_name="" condition is set, then both the case when display_name is set as an empty string and the case when it is not set at all will fall under this condition);
• sorm_digits — the subscriber's number that will be transferred to the SORM control panel (only for Russia);
• sorm_ni — the sign of the subscriber that will be transferred to the SORM control panel (only for Russia);
• category — the category of subscriber A, can take a string or numeric value according to the table 1.

Table 1 — Subscriber categories 

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.

<rgn digits="Digits" 
     nai="Nai" 
     incomplete="boolean" 
     npi="Npi" 
     apri="Apri" 
     ni="Ni" 
     empty="Empty"
     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;
• 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 RedirectingNumber 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 — RedirectingNumber is present;
• 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. 

<time>

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

where:

• HH — hours;
• MM — minutes.

<time value="TimeMask"/>

where:

• value — mask of the time of day.

<date>

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

where:

• DD — day;
• MM — month;
• YYYY — year.

<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"

where:

• DAY — number of the day of the week (numbers from 1 to 7). It can be specified from 1 to 7 days of the week.

It works according to the Gregorian calendar.

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

where:

• 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="Timetable" />

where:

• value — the name of the schedule. Schedules are configured with the commands /domain/<DOMAIN>/calendar/timetable/ or Calendar web configurator application.

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

<tag value="Tag"/>

where:

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

<final value="boolean"/>

where:

• 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 value="Cause"/>

where:

• cause — the reason of disconnection.

<ocdpn>

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

<ocdpn digits="Digits" 
     nai="Nai" 
     incomplete="boolean" 
     npi="Npi" 
     apri="Apri" 
     ni="Ni" 
     empty="Empty" 
     category="Category"
     in_list="listName"/>

• 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> 

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

The description of the <conditions> element has the following form:

<actions>
  <set_options/>
  <cgpn/>
  <cdpn/>
  <rgn/>
  <restore_cgpn/>
  <restore_rgn/>
  <empty_rgn/>
  <restore_cdpn/>
  <calling/>
  <called/>
  <final/>
  <alarm/>
  <log/>
  <cause/>
  <external_routing/>
  <ocdpn/>
  <restore_ocdpn>
</actions>

where:

• set_options — setting various call parameters;
• cgpn — modification of the parameters of the caller's number;
• cdpn — modification of the parameters of the number of the called subscriber;
• rgn — modification of the parameters of the number that performed the forwarding
• restore_cgpn — restoring the parameters of the caller's number to the values that were when entering the current context (canceling changes within the context);
• restore_cdpn — restoring the parameters of the called subscriber's number to the values that were when entering the current context (canceling changes within the context);
• restore_rgn — restoring the original values of the parameters of the number that performed the redirection
• empty_rgn — restoring the original values of the parameters of the number of the called subscriber;
• calling — modification of the caller's access parameters (the structure is similar to the "calling" parameter from the <conditions> element);
• called — modification of the access parameters of the called subscriber for SORM (the structure is similar to the "called" parameter from the <conditions> element);
• final — setting the sign of the end of the set;
• alarm — sending an accident;
• log — writing a message to the log;
• cause — installation of the causes by which you need to perform routing by goats;
• external_routing — calling an external routing service (currently only external Radius routing is supported);
• ocdp — operation of modification of parameters of the original number to which the call was made;
• restore_ocdp — restoring the original parameter values of the original number to which the call was made, which were when entering the routing context;
• empty_ocdp — remove the OriginalCalledNumber parameter from the alarm.

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.

Example of setting the IVR variable of the CARD_PLATFORM_TO_NUMBER script. The variable is set to the characters entered after the exit number on the IVR script:

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

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

where:

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

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

where:

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

<calling category="atomType"
         caller_id="stringType"
         display_name="stringType"
         sorm_digits="stringType"
         sorm_ni="atomType"/>

The syntax of the "caller_id" attribute is similar to the "digits" field in "cgpn".

The description of the parameters is similar to the description of the "calling" parameters of the "conditions" section.

Setting the caller ID number. The syntax of the "caller_id" attribute is similar to the "digits" field in "cgpn".

Example of setting "caller_id", adding "8" to the number from "cgpn":

<conditions>
   <cgpn digits="%"/>
</conditions>
<actions>
   <calling caller_id="8{%}"/>
</actions>

The display_name parameter allows replacing the display name of subscriber A when routing a call. This field has a test type, supports the following macro variables:

• %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.

<alarm severity="alarmSeverity"
 value="string"/>

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

<log severity="logSeverity"
  value="string"/> 

• 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:

• causes of ACP (ACP causes) — list of ACP goats;
• causes of ISUP (ISUP causes) — list of ISUP goats;
• SIP causes — a list of SIP goats.
  At the level of the routing context, the actions block is added to the cause block:

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

<external_routing id="stringType"
                             service="stringType"
                             timeout="positiveIntegerType"/>

• id — list of names of RADIUS servers to which external routing requests will be sent. The list is separated by a semicolon. If multiple servers are specified, the request will be sent to the next server only if the previously standing server is unavailable. The list of servers can be viewed with the command @/domain/<DOMAIN>/radius/info@;
• service — radius_route_service — external routing by RADIUS;
• timeout — waiting time for the result from the external routing service, in milliseconds. By default, 500 ms is set. If external routing does not complete during this time, the system will perceive that routing has not made any changes.

Example of calling external routing using RADIUS servers named master and backup, with a request timeout of 1 second:

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

<ocdpn digits="Digits" 
       nai="Nai" 
       incomplete="boolean" 
       npi="Npi" 
       apri="Apri" 
       ni="Ni" 
       category="Category"/>

• 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> 

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

<result>
 Result
</result>

where:

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

Simplified syntax:

<result>
 <local/>
</result>

Syntax for the case of continued routing if the subscriber was not found in the database of local subscribers:

<result>
 <local>
   <continue tag="not_local"/>
 <local/>
</result>

Syntax for searching for a local subscriber by the entered vdn attribute:

<rule name="local_calls">
  <conditions>
    <cdpn digits="1???%"/>
  </conditions>
  <result>
    <local vdn="{1,2,3,4}"/>
  </result>
</rule>

The following syntax is used to set the vdn attribute:

<local vdn="[CGPN|CDPN|RGN{DIGITS}]"/>

By default, the value is taken from cdpn.

where:

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

Syntax:

<result>
 <ivr script="IvrScript"/>
</result>

where:

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

When the flag is set, 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.

Syntax:

<result>
   <external>
      <trunk value="Interface1" weight="50" max_load="80%"/>
      <trunk value="Interface2" weight="50" max_load="80%"/>
      <trunk value="Interface3" weight="10"/>
   </external>
</result>

where:

• trunk — description of the interface corresponding to the exit from the virtual PBX (domain). Corresponds to the trunk on the bridge, or some kind of gateway. Multiple interfaces can be specified, which defines a set of SL beams in one direction;
• value — string with the interface name;
• weight — weight of the interface, a number, an optional parameter that indicates the priority of channel occupation in a particular SL beam in the direction. In the rule, weights are either set for all interfaces, or they are not set for any interface. Depending on whether the weights are set or not, the mode of selecting the interface from the list is determined (when there are more than 1 of them). If the weights are set, then as a result of routing, a sorted list of interfaces is returned taking into account these weights (for each routing, when the rule is triggered, the interfaces are "reweighed" and re-sorted). If the weights are not specified, the router returns a list of interfaces in the order they are specified in the configuration. The further logic of working with this list is implemented in the kernel and consists in the fact that the first interface from the list is taken, an attempt is made to establish a connection through this interface, if it ends due to an overload of the interface or its busy, then an attempt is made to establish a connection through the next interface on the list, etc;
• max_load — maximum interfaces load (as a percentage, or in the number of calls), is interpreted as follows: if the Number% is specified, it means the trunk load as a percentage of the maximum load (the maximum load is set at the interface level). If just a number is specified, it means the number of active calls within this trunk. As a result, if at the time of routing the load is less than specified in max_load, go in the specified direction. Otherwise, try to take the next direction.

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

Syntax:

<result>
  <direction value="DirectionName"/>
</result>

where:

• value — the name of the 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.

Syntax:

<result>
 <incomplete timeout="TimeoutInMilliseconds"/>
</result>

where:

• timeout — optional parameter, number, number of milliseconds of waiting for digits of the number.

<no_route>

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

Syntax:

<result>
 <no_route isup_cause="ISUPCause"/>
</result>

where:

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

Syntax:

<result>
 <continue context="ContextName" tag="Tag"/>
</result> 

where:

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

Syntax:

<result>
    <next tag="Tag"/>
</result>

where:

• 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 

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

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

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

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.

The number mask is set as a string in which the number is entered for comparison. The range can be specified via "-", or listed via ",". The range, or enumeration is enclosed in parentheses "(" ")" The following service characters are also possible:

• "?" — any non-empty element of the number (digits 0-9, or letters A, B, C, D);
• "%" — 0 or several elements of the number (attention: there can be no other characters after the "%" character).

To compare the common prefix of cgpn, cdpn, ocdpn, rgn parameters with each other, the following syntax is used [cgpn|cdpn|rgn|ocdpn{DIGITS}].

For the rule, the number of number masks is limited to 256. If ranges of numbers are specified in the conditions, then when compiling the context, several masks can be formed for each range of numbers. For example, masks will be formed for the range 100-400: 1??, 2??, 3??, 4??.

<conditions>
 <cgpn digit="345???????"/>
</conditions>

<conditions>
  <cgpn digit="%"/>
</conditions>

<conditions>
 <cdpn digit="???"/>
</conditions>

<conditions>
  <cdpn digit="(1-3)7%"/>
</conditions>

<conditions>
 <cdpn digits="????"/>
 <cgpn digits="[cdpn{1,2}]??"/>
</conditions>

Known errors when comparing parameters:

• 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 

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.

Regular expressions are the most flexible way to do all possible conversions, but it has significant drawbacks:

• syntax complexity — regular expressions are a universal mechanism used in various fields of information technologies. It has its own complex description language, which increases the input threshold of the knowledge of the person who uses them;
• computational complexity — calculating the result of modification based on regular expressions (including in the recompiled version) requires large computational resources compared to modification on templates.

To get rid of the disadvantages of regular expressions, the ECSS-10 system uses a modification of the number on the templates.

When modifying a number, the following notation is used:

• each digit of the original number (before modification) is indicated either by a number describing its position, or by a letter of the English alphabet at the corresponding position (the original seven-digit number without modification can be written as: "1,2,3,4,5,6,7" or "abcdefg");
• as in the conditions for triggering rules, the special symbol "%" is supported, which means the part of the number that corresponds to the % symbol in the <conditions> section (we can assume that at the stage of the rule condition, a variable named "%" is formed for the corresponding number, which is filled in with the digits of the number, and at the modification stage it is used);
• in order to be able to modify the number (subscriber A or subscriber B), it must be present in the <conditions> element of the rule (this guarantees compliance with the number format);
• in order for modifications with certain digits in the number to be possible, in the <conditions> element, in the condition for the corresponding number, the digits in the required positions must either be the digits of the number themselves (a template for digits), or the digits must be closed with special characters "?";
• for rules that process a number of arbitrary length (in the <conditions> element for the digits of the number there is a condition with a special symbol "%"), only prefixing (adding an additional prefix) or post-fixing (adding a postfix at the end of the number) is possible;
• if it is necessary to insert additional digits that were not included in the original number, then they are simply written in the "digits" field in the desired position, the indication of the actual digits of the number from 0 to 9 and the letters A, B, C, D (or a,b,c,d) is supported;
• if you want to write the elements of the source number in the form of codes (position numbers, or letter codes), or in the form of a special character "%", then they are written in curly brackets (for example {abc}, or {3,5,4}, or {5,%};
• to copy some digits from cgpn to cdpn, rgn, ocdpn (similarly for other types of numbers) that match within the conditions section, [cgpn|cdpn|rgn|ocdpn{DIGITS,%}] is used in the actions section.

Examples

Removing prefix from a ten-digit number:

<conditions>
  <cgpn digits="345???????"/>
</conditions>
<actions>
  <cgpn digits="{4,5,6,7,8,9,10}"/>
</actions>

Removing the 345 prefix from a number of arbitrary length with prefix 345:

<conditions>
  <cgpn digits="345%"/>
</conditions>
<actions>
  <cgpn digits="{%}"/>
</actions>

Permutation of digits 2 and 3 in a three-digit number (any digits):

<conditions>
  <cgpn digits="???"/>
</conditions>
<actions>
  <cgpn digits="{1,3,2}"/>
</actions>

Prefixing an arbitrary three-digit number with the prefix 008:

<conditions>
  <cgpn digits="???"/>
</conditions>
<actions>
  <cgpn digits="008{1,2,3}"/>
</actions>

Swapping cdpn and cgpn:

<conditions> 
<cgpn digits="%"/> 
<cdpn digits="%"/> 
</conditions> 
<actions> 
<cgpn digits="[cdpn{%}]"/> 
<cdpn digits="[cgpn{%}]"/> 
</actions> 

A rule that can be used to exit to an intercity station. In particular, it can be seen that the rule will work for calls in which subscriber A has a seven-digit local number, subscriber B's number starts at 8. The task of the modification is to convert a local number to a long-distance one that understands intercity, for this the prefix is appended and "ni" and "nai" are changed. Number B does not change, the intercity is engaged in its analysis.

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

Example of a context for routing either to a local subscriber or to a 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.

Usually, gateways (especially SIP gateways) work in the enblock mode, but when trying to use any service (for example, call transfer), routing of the entered number occurs in the 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.

<cause acp="ACPCauses" isup="ISUPCauses" sip="SIPCauses"/>

where:

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

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

In case of simultaneous indication of several reasons for disconnection, the rule will work if at least one of the reasons coincides.

At the moment, it is possible to analyze not only the "Cause" for which the call was rejected, but also its initiator. There are 3 causeinitiators available: system, network, user.

• System — reason related to the internal logic of call processing on ECSS-10;
• Network — hang-up occurred from the network side (trunk direction);
• User — hang-up occurred on the side of the user.

Example of configuration on ECSS-10:

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

The effect of "Cause" routing on other subsystems:

• CDR — on CDR, routing looks like several independent calls with the same conn_id;
• AAA — on AAA, routing looks like several independent calls, while unsuccessful calls are sent to AAA only if the unsuccessful_call_info = true (domain/<DOMAIN>/aaa/accounting/set) property is enabled.
  
  

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>

• <$ROUTE_RETRIES> — number of the call routing attempt;
• <$ROUTE_CAUSE_ISUP> — ISUP is the reason of rejecting the previous call;
• <$ROUTE_CAUSE_SIP> — SIP is the reason of rejecting the previous call;
• <$ROUTE_CAUSE_ACP> — ACP is the reason of rejecting the previous call.