Yeti Switch

Appearance

Routing Tags ​

Routing Tags are used for creating transparent routing rules within Yeti's routing logic. Routing Tags for every call are detected after processing call with using Numberlists <numberlists>{.interpreted-text role="ref"} on the basis Routing Tag detection Rules <routing_tag_detection_rules>{.interpreted-text role="ref"} and later they could be used for choosing Destinations <destinations> and Dialpeers <dialpeers> for the call routing.

Example of using Routing Tags for marking calls is represented on the picture below:

::: graphviz ../graphviz/routing_tags.dot :::

At the beginning of routing procedure the call hasn't any Routing Tags.

During the Authentication procedure <customer_auth_algorithm>{.interpreted-text role="ref"} Yeti could change state of Routing Tags for the call. As it shown on picture (example) above Customers Auth <customer_auth> settings contain Append selected tags in the Routing Tags options <routing_tags_options>{.interpreted-text role="ref"} with Tag action value = Tag1; Tag2; Tag3. As a result of Customers Auth <customer_auth> Tags Processing procedure Yeti will append to the call three Routing Tags: Tag1, Tag2 and Tag3.

The next step where Routing Tags can be changed - Destination Numberlist <numberlists> Tags Processing procedure. As it shown on picture (example) above Destination Numberlist <numberlists> settings contain Remove selected tags in the Routing Tags options <numberlists_routing_tags_options>{.interpreted-text role="ref"} with Tag action value = Tag2. As a result of Destination Numberlist <numberlists> Tags Processing procedure Yeti will remove from the call one Routing Tag: Tag2. Resulting state of call's Routing Tags after this procedure is: Tag1 and Tag3.

The next step where Routing Tags can be changed - Source Numberlist <numberlists> Tags Processing procedure. As it shown on picture (example) above Source Numberlist <numberlists> settings contain Intersection with selected tags in the Routing Tags options <numberlists_routing_tags_options>{.interpreted-text role="ref"} with Tag action value = Tag2, Tag3, Tag4. As a result of Source Numberlist <numberlists>{.interpreted-text role="ref"} Tags Processing procedure Yeti will remove from the call all Routing Tags that aren't presented in both intersected sets. Resulting state of call's Routing Tags after this procedure is: Tag3.

The last step where Routing Tags can be changed - Routing Tag detection Rule <routing_tag_detection_rules>{.interpreted-text role="ref"} Tags Processing procedure. As it shown on picture (example) above Routing Tag detection Rule <routing_tag_detection_rules>{.interpreted-text role="ref"} settings contain Clear tags in the Routing Tags options <routing_tag_detection_rules_tag_action>{.interpreted-text role="ref"} with Tag action value = null. As a result of Routing Tag detection Rule <routing_tag_detection_rules>{.interpreted-text role="ref"} Tags Processing procedure Yeti will remove from the call all Routing Tags. Resulting state of call's Routing Tags after this procedure is: null.

Principles of the Routing tags <routing_tag>{.interpreted-text role="ref"} matching are described in this Example (Truth table for tags) <tags_truth_table>{.interpreted-text role="ref"}.

Example of using Routing Tags for selecting Destinations <destinations> and Dialpeers <dialpeers> records for the call routing is represented on the picture below:

::: graphviz ../graphviz/routing_tags_using.dot :::

As you can see on this picture above, after the routing procedure Call has three Tags: Tag1; Tag2; Tag3. At same time in the Yeti's Database three ref:[Destinations <destinations>]{.title-ref} and three Dialpeers <dialpeers> records are stored:

  • Destination 1 is marked by three Tags Tag1; Tag2; Tag3 and AND mode used for the comparison of Routing Tags;
  • Destination 2 is marked by Tag1 only and OR mode used for the comparison of Routing Tags;
  • Destination 3 is marked by Tag1 only and AND mode used for the comparison of Routing Tags;
  • Dialpeer 1 is marked by Tag1; Tag2; Tag3 and AND mode used for the comparison of Routing Tags;
  • Dialpeer 2 is marked by Tag2 only and AND mode used for the comparison of Routing Tags;
  • Dialpeer 3 is marked by Tag1; Tag2; Tag3; Tag4 and AND mode used for the comparison of Routing Tags.

After selection procedures with using parameters above only two Destinations (Destination 1 and Destination 2) and one Dialpeer (Dialpeer 1) records were selected via following reasons:

  • Destination 3 wasn't selected because in AND mode of comparison record should contain the same set of Routing Tags, but in the example above it contains only one Tag;
  • Dialpeer 2 wasn't selected by the same reasons (in AND mode of comparison record should contain the same (with a call) set of Routing Tags;
  • Dialpeer 3 wasn't selected because this record contains one additional Tag (Tag4) and could not be selected in the AND mode.

Routing Tag's attributes: ​

:::

Id
Unique Routing Tag's id.
Name
Unique Routing Tag's name. :::