Skip to content

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.

  1. Create a Routing tag named VIP.
  2. Create an Area VIP customers and add the CLI numbers (or prefixes) of your VIP customers as Area prefixes.
  3. Create a Routing Tag detection rule: Src area = VIP customers → assign tag VIP.
  4. 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:

  1. Create an Area Country X with the relevant number prefixes.
  2. Create a Routing tag From-CountryX.
  3. Create a Tag detection rule: Src area = Country X → assign tag From-CountryX.
  4. 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 value field bellow (if any were chosen) from the call
Append selected tags
Appends tags 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 tags that were chosen in the Tag action value field 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 tagsTag1Tag1, Tag2Tag2
No tags3000
Tag 10300
Tag 1, Tag 20030
Tag 1, Tag 2, Any0030
Tag 1, Tag 30000
Tag 1, Any0310
Tag 20000
Tag 2, Any0010
Any0111

OR tag comparison mode

Call Tags ⇨
Dialpeer Tags ⇩
No tagsTag1Tag1, Tag2Tag2
No tags3000
Tag 10300
Tag 1, Tag 20232
Tag 1, Tag 2, Any0232
Tag 1, Tag 30200
Tag 1, Any0311
Tag 20000
Tag 2, Any0111
Any0111

IN tag comparison mode

Call Tags ⇨
Dialpeer Tags ⇩
No tagsTag1Tag1, Tag2Tag2
No tags3000
Tag 10330
Tag 1, Tag 20333
Tag 1, Tag 2, Any0333
Tag 1, Tag 30330
Tag 1, Any0331
Tag 20033
Tag 2, Any0133
Any0111

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.