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