h1. Routing table sorting

{{>toc}}

The logic for sorting the routing table is contained in the [[Hunting Classes (Telephony)|Hunting class]] entity.
A *Hunting class* is a set of [[Metrics (Telephony) | Metrics]] and the specified settings *for rounding the values of metrics*.
Together, these parameters determine how the routing table will be ordered, and therefore the order diling the outbound peers.

h2. Strict sorting.

This is the simplest sorting strategy.
The system compares the routes with each other according to the configured metrics and determines the position of each route in the final routing table.
To do this, each route is compared with others according to a set of configured metrics.

For each metric, you can specify a priority - the degree of importance of this metric.
The metric with the lower priority value is applied first.
If it turns out that one route is definitely better than the other in terms of this metric, the comparison stops.
If the routes are the same for a given metric, then the routes are compared according to the next, lower priority, metric.

For example, we have route A and route B.
[[Hunting Classes (Telephony) | Hunting Class]] has metrics configured in the following order:
# price
# [[ASR indicator|ASR]] route

Then, when *Smartswitch* will choose between routes to determine a higher priority, first of all it will compare the prices for route code A and route B and select the route with a lower price.
If the prices are the same, it will compare the [[ASR indicator|ASR]] and select the route with the best [[ASR indicator|ASR]].

h2. Rounded sorting

*Rounded sorting* occurs when you specify *rounding* for [[Metrics (Telephony)|Metrics]].
In this case, you tell the system that you want to consider the routes equal for a certain metric, if the value of this metric differs within certain limits.
And these routes should be compared according to the next highest priority metric.

For example, we have route A and route B.
A [[Hunting classes (Telephony)|Hunting class]] which is configured has metrics configured in the following order:
# [[ASR indicator|ASR]] route
# price

Suppose that route A has [[ASR indicator|ASR]] of 11%, and route B has 12%, which are generally similar values.
If we do not specify rounding for the +ASR metric of a route+, then route B will always be considered more preferable.
However, if we tell the system that [[ASR indicator|ASR]] can be rounded to 5%, then [[ASR indicator|ASR]] for Route A and Route B will round up to 15% and the system will consider them the same and will compare routes by price.

*Rounded sorting* is almost always needed for:

  * [[Routing based on telephone traffic metrics]].
  * [[Routing based on telephone traffic target metrics]].

See also:
* [[Metrics (Telephony)|Metrics]]

[[Сортировка таблицы маршрутизации|Русский перевод]]