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 on the basis Routing Tag detection Rules and later they could be used for choosing Destinations and Dialpeers for the call routing.
Example of using Routing Tags for markuping call is represented on the picture below:
![digraph General {
node [style=filled; fillcolor="#FCF9A5"];
graph [nodesep=1, ranksep=0.2, mindist=0.5];
subgraph cluster_Settings {
style=filled;
color=lightgrey;
node [style=filled,color=orange];
s_1 [label = "Customer Auth's Tag action: \n **Append selected tags** \n Customer Auth's Tag action value: Tag1; Tag2; Tag3"; shape=box; sides=4];
s_2 [label = "Destination Numberlist's Tag action: \n **Remove selected tags** \n Destination Numberlist's Tag action value: Tag2"; shape=box; sides=4];
s_3 [label = "Source Numberlist's Tag action: \n **Intersection with selected tags** \n Source Numberlist's Tag action value: Tag2, Tag3, Tag4"; shape=box; sides=4];
s_4 [label = "Routing Tag detection Rule's Tag action: \n **Clear tags** \n Routing Tag detection Rule's Tag action value: **null**"; shape=box; sides=4];
s_1 -> s_2 [style=invis];
s_2 -> s_3 [style=invis];
s_3 -> s_4 [style=invis];
label = "Settings";
}
subgraph cluster_Procedure {
style=filled;
color=lightgrey;
node [style=filled,color=green];
p_1 [label = "Customer Auth Tags Processing"; shape=box; sides=4];
p_2 [label = "Destination Numberlist Tags Processing"; shape=box; sides=4];
p_3 [label = "Source Numberlist Tags Processing"; shape=box; sides=4];
p_4 [label = "Routing Tag detection Rule Tags Processing"; shape=box; sides=4];
p_1 -> p_2 [style=invis];
p_2 -> p_3 [style=invis];
p_3 -> p_4 [style=invis];
label = "Procedures";
}
subgraph cluster_RT {
style=filled;
color=lightgrey;
node [style=filled,color=blue];
rt_1 [label = "**null**"; shape=Msquare; sides=4];
rt_2 [label = "Tag1; Tag2; Tag3"; shape=Msquare; sides=4];
rt_3 [label = "Tag1; Tag3"; shape=Msquare; sides=4];
rt_4 [label = "Tag3"; shape=Msquare; sides=4];
rt_5 [label = "**null**"; shape=Msquare; sides=4];
rt_1 -> rt_2 [style=invis];
rt_2 -> rt_3 [style=invis];
rt_3 -> rt_4 [style=invis];
rt_4 -> rt_5 [style=invis];
label = "State of call's Routing Tags:";
}
rt_1 -> p_1;
s_1 -> p_1;
p_1 -> rt_2;
rt_2 -> p_2;
s_2 -> p_2;
p_2 -> rt_3;
rt_3 -> p_3;
s_3 -> p_3;
p_3 -> rt_4;
rt_4 -> p_4;
s_4 -> p_4;
p_4 -> rt_5;
}](../../_images/graphviz-3ad3ebdc7c4edb1b2280a0d02453072ac7bc8672.png)
At the beginning of routing procedure the call hasn’t any Routing Tags.
During the Authentication procedure Yeti could change state of Routing Tags for the call. As it shown on picture (example) above Customers Auth settings contain Append selected tags in the Routing Tags options with Tag action value = Tag1; Tag2; Tag3. As a result of Customers 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 Tags Processing procedure. As it shown on picture (example) above Destination Numberlist settings contain Remove selected tags in the Routing Tags options with Tag action value = Tag2. As a result of Destination Numberlist 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 Tags Processing procedure. As it shown on picture (example) above Source Numberlist settings contain Intersection with selected tags in the Routing Tags options with Tag action value = Tag2, Tag3, Tag4. As a result of Source Numberlist 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 Tags Processing procedure. As it shown on picture (example) above Routing Tag detection Rule settings contain Clear tags in the Routing Tags options with Tag action value = null. As a result of Routing Tag detection Rule 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 matching are described in this Example (Truth table for tags).
Example of using Routing Tags for selecting Destinations and Dialpeers records for the call routing is represented on the picture below:
![digraph General {
node [style=filled; fillcolor="#FCF9A5"];
graph [nodesep=1, ranksep=0.2, mindist=0.5];
subgraph cluster_RT1 {
style=filled;
color=lightgrey;
node [style=filled,color=blue];
rt_1_1 [label = "Tag1; Tag2; Tag3"; shape=Msquare; sides=4];
label = "State of call's Routing Tags:";
}
subgraph cluster_Procedure1 {
style=filled;
color=lightgrey;
node [style=filled,color=green];
p_1_1 [label = "Destinations selection"; shape=box; sides=4];
p_1_2 [label = "Dialpeers selection"; shape=box; sides=4];
p_1_1 -> p_1_2 [style=invis];
label = "Procedures";
}
subgraph cluster_Settings1 {
style=filled;
color=lightgrey;
node [style=filled,color=orange];
s_1_1 [label = "Tag mode value for Destination 1: \n **AND** \n Tag ids value for Destination 1: Tag1; Tag2; Tag3"; shape=box; sides=4];
s_1_2 [label = "Tag mode value for Destination 2: \n **OR** \n Tag ids value for Destination 1: Tag1"; shape=box; sides=4];
s_1_3 [label = "Tag mode value for Destination 3: \n **AND** \n Tag ids value for Destination 1: Tag1"; shape=box; sides=4];
s_1_4 [label = "Tag mode value for Dialpeer 1: \n **AND** \n Tag ids value for Dialpeer 1: Tag1; Tag2; Tag3"; shape=box; sides=4];
s_1_5 [label = "Tag mode value for Dialpeer 2: \n **AND** \n Tag ids value for Dialpeer 1: Tag2"; shape=box; sides=4];
s_1_6 [label = "Tag mode value for Dialpeer 3: \n **AND** \n Tag ids value for Dialpeer 1: Tag1; Tag2; Tag3; Tag4"; shape=box; sides=4];
s_1_1 -> s_1_2 [style=invis];
s_1_2 -> s_1_3 [style=invis];
s_1_3 -> s_1_4 [style=invis];
s_1_4 -> s_1_5 [style=invis];
s_1_5 -> s_1_6 [style=invis];
label = "Settings";
}
subgraph cluster_Selected1 {
style=filled;
color=lightgrey;
node [style=filled,color=orange];
sl_1_1 [label = "Destination 1"; shape=box; sides=4];
sl_1_2 [label = "Destination 2"; shape=box; sides=4];
sl_1_4 [label = "Dialpeer 1"; shape=box; sides=4];
sl_1_1 -> sl_1_2 [style=invis];
sl_1_2 -> sl_1_4 [style=invis];
label = "Selected Records";
}
rt_1_1 -> p_1_1;
rt_1_1 -> p_1_2;
s_1_1 -> p_1_1;
s_1_2 -> p_1_1;
s_1_3 -> p_1_1;
s_1_4 -> p_1_2;
s_1_5 -> p_1_2;
s_1_6 -> p_1_2;
p_1_1 -> sl_1_1;
p_1_1 -> sl_1_2;
p_1_2 -> sl_1_4;
}](../../_images/graphviz-13299e58827b19e2524de9ffcc73aa8b2a6daca2.png)
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> and three Dialpeers records are stored:
Destination 1 is marked by three Tags Tag1; Tag2; Tag3 and AND mode used for the comparision of Routing Tags;
Destination 2 is marked by Tag1 only and OR mode used for the comparision of Routing Tags;
Destination 3 is marked by Tag1 only and AND mode used for the comparision of Routing Tags;
Dialpeer 1 is marked by Tag1; Tag2; Tag3 and AND mode used for the comparision of Routing Tags;
Dialpeer 2 is marked by Tag2 only and AND mode used for the comparision of Routing Tags;
Dialpeer 3 is marked by Tag1; Tag2; Tag3; Tag4 and AND mode used for the comparision 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 comparision 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 comparision 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.