Using Routing tags
Routing tags let you apply different routing and billing logic to calls based on where they come from, where they go, or who is making them — without creating separate routing plans for each case.
The idea is straightforward: you label certain calls with a tag during the routing process, then configure your Destinations and Dialpeers to respond to that tag. Tagged calls get routed differently from untagged ones.
How it works
Each call carries a set of tags that starts empty and gets built up as the call moves through the routing pipeline. Several places in the pipeline can add, remove, or replace tags — see the Call tags modifications section for the full list of available actions.
Once the final tag set is determined, Yeti uses it to select the right Destinations and Dialpeers — entries that match the call's tags are preferred over generic ones.
The most common way to assign tags based on geographic origin or destination is through Routing Tag detection rules, which combine source/destination Areas with number prefixes. But tags can also be assigned directly in Customer Auth or Numberlists — useful when you want to tag calls by customer or by a specific number pattern rather than by geography.
Example: premium routing for VIP customers
Suppose you want calls from your VIP customers to always use a higher-quality carrier, while regular customers use the standard route.
- Create a Routing tag named VIP.
- Create an Area VIP customers and add the CLI numbers (or prefixes) of your VIP customers as Area prefixes.
- Create a Routing Tag detection rule: Src area = VIP customers → assign tag VIP.
- Configure a high-quality Dialpeer and set its Routing tag to VIP.
Example: origin-based billing
You can also use areas to apply different rates depending on where a call originates. For instance, charge calls coming from a specific country at a different rate:
- Create an Area Country X with the relevant number prefixes.
- Create a Routing tag From-CountryX.
- Create a Tag detection rule: Src area = Country X → assign tag From-CountryX.
- Create a separate Destination with the From-CountryX tag and the desired rate.
Calls from that country will match the tagged Destination and be billed accordingly; all other calls continue to use the standard Destination.
How tags affect Destination and Dialpeer selection
Once the call's tags are finalized, Yeti uses them to filter and rank both Destinations (for billing) and Dialpeers (for routing).
The key principle is simple: a Destination or Dialpeer only participates in routing if its tag configuration is compatible with the call's tags. Among all compatible options, those with a more specific tag match are preferred over generic ones.
Destination selection
When looking up a Destination, Yeti considers only those whose tag configuration matches the call. If two destinations cover the same number prefix, the one with the more specific tag match wins. For example, a destination tagged VIP beats a destination with the Any wildcard tag when the call carries the VIP tag.
Dialpeer selection
The same logic applies to Dialpeers. Yeti first discards any dialpeer whose tags are incompatible with the call. Among the remaining dialpeers, for each vendor the best-matching one is selected — again preferring the longer prefix and, for equal prefixes, the more specific tag match.
This means you can configure a vendor with two dialpeers for the same destination prefix: one tagged for a specific traffic type (e.g. VIP) and one with the Any wildcard as a fallback. VIP calls will use the dedicated dialpeer; all other calls will use the fallback.
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 tags from the call (if any were added early);
- Remove selected tags
- Removes only tags that were chosen in the
Tag action valuefield bellow (if any were chosen) from the call - Append selected tags
- Appends tags that were chosen in the
Tag action valuefield bellow (if any were chosen) to the call; - Intersection with selected tags
- Yeti leaves as is tags that were chosen in the
Tag action valuefield bellow (if any were chosen) in the call and removes any other tags 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.