Using Routing tags
The Yeti Switch has rich abilities for routing traffic. And one of them is tags.
Let's imagine that you need to route some calls relying on their A or B numbers (or even both) - that's not a problem.
We have to use the next entities for that (see the "Routing" menu group): Routing tags - we attach them to dialpeers. It holds areas within. Areas - implies some geographic area (or whatever you want) and holds prefixes within. Area prefixes - that's where our A or B prefixes live. Routing tags detection - the place where the magic goes. I.e. there we combine a Routing Tag with Areas.
I think I'll better show you a diagram

Here, we've created the special tag named VIP for Bender (we check his A number) who calls to Robonia (we check its prefixes).
We can easily create another one Routing tag and Routing tag detection, where we may use the same ROBONIA area as Src area for calls so that we could detect calls from Robonia to our system (maybe, we don't want to charge them or on the contrary charge them more).
What's the next? Now, we may attach our newly created tag to a dialpeer

So, if any particular call already has a tag than Yeti is going to choose dialpeers having such a tag, than all others dialpeers. If a call don't have any tags than a routing decision will be based on all dialpeers.
Call tags modifications
On different routing steps Yeti may modify call tags using Tag Action and Tag Action Value settings
- Tag action
Describes one of the possible actions that could be applied to the current set of call Routing Tags. Following actions can be selected in this field:
- Clear tags
- Removes all Routing Tags <routing_tag> from the call (if any were added early);
- Remove selected tags
- Removes only Routing Tags <routing_tag> that were chosen in the Tag action value field bellow (if any were chosen) from the call
- Append selected tags
- Appends Routing Tags <routing_tag> that were chosen in the Tag action value field bellow (if any were chosen) to the call;
- Intersection with selected tags
- Yeti leaves as is Routing Tags <routing_tag> that were chosen in the Tag action value field bellow (if any were chosen) in the call in case of their presence in the current set of Routing Tags <routing_tag>{.interpreted-text role="ref"} and removes any other Routing Tags <routing_tag> from the call.
- Replace with selected tags
- Current call tags will be replaced with tags defined in
Tag action value
- Tag action value
In this field Routing Tags for making some Tag action above could be chosen.
Truth table for tags
Truth table for Routing Tags is used for better understanding how different modes of routing tag comparation are used for selecting dialpeers that are related to the current call. Rows, in the table bellow, represent eight different states of Dialpeer Tags each of them are presented by two comparation modes (OR & AND). At same time, columns represent four different states of Call Tags. In the cells at the intersection of these states different levels of matching are presented. The highest level of matching is 3, the lowest level is 0. During selection of Dialpeers, in case if two or more Dialpeers have level of matching with current call (by comparation Dialpeer Tags and Call Tags) more than 0, Dialpeers with highest level of matching will be selected.
AND tag comparison mode
| Call Tags ⇨ Dialpeer Tags ⇩ | No tags | Tag1 | Tag1, Tag2 | Tag2 |
|---|---|---|---|---|
| No tags | 3 | 0 | 0 | 0 |
| Tag 1 | 0 | 3 | 0 | 0 |
| Tag 1, Tag 2 | 0 | 0 | 3 | 0 |
| Tag 1, Tag 2, Any | 0 | 0 | 3 | 0 |
| Tag 1, Tag 3 | 0 | 0 | 0 | 0 |
| Tag 1, Any | 0 | 3 | 1 | 0 |
| Tag 2 | 0 | 0 | 0 | 0 |
| Tag 2, Any | 0 | 0 | 1 | 0 |
| Any | 0 | 1 | 1 | 1 |
OR tag comparison mode
| Call Tags ⇨ Dialpeer Tags ⇩ | No tags | Tag1 | Tag1, Tag2 | Tag2 |
|---|---|---|---|---|
| No tags | 3 | 0 | 0 | 0 |
| Tag 1 | 0 | 3 | 0 | 0 |
| Tag 1, Tag 2 | 0 | 2 | 3 | 2 |
| Tag 1, Tag 2, Any | 0 | 2 | 3 | 2 |
| Tag 1, Tag 3 | 0 | 2 | 0 | 0 |
| Tag 1, Any | 0 | 3 | 1 | 1 |
| Tag 2 | 0 | 0 | 0 | 0 |
| Tag 2, Any | 0 | 1 | 1 | 1 |
| Any | 0 | 1 | 1 | 1 |
IN tag comparison mode
| Call Tags ⇨ Dialpeer Tags ⇩ | No tags | Tag1 | Tag1, Tag2 | Tag2 |
|---|---|---|---|---|
| No tags | 3 | 0 | 0 | 0 |
| Tag 1 | 0 | 3 | 3 | 0 |
| Tag 1, Tag 2 | 0 | 3 | 3 | 3 |
| Tag 1, Tag 2, Any | 0 | 3 | 3 | 3 |
| Tag 1, Tag 3 | 0 | 3 | 3 | 0 |
| Tag 1, Any | 0 | 3 | 3 | 1 |
| Tag 2 | 0 | 0 | 3 | 3 |
| Tag 2, Any | 0 | 1 | 3 | 3 |
| Any | 0 | 1 | 1 | 1 |
Levels of matching:
- 0 - Dialpeer does not match;
- 1 - Dialpeer could be selected because ANY TAG mode was enabled;
- 2 - Dialpeer could be selected because one of the Tags is coincided (only for OR mode);
- 3 - Dialpeer could be selected because all Dialpeer's tags are the same as call's tags.