Skip to content

Weighted distribution

Weighted distribution shares traffic between vendors in fixed proportions instead of always preferring the same one. For every call it picks the order of the weighted entries at random, giving each entry a chance in proportion to its Weight. Use it to keep several vendors busy, to test a new vendor on a slice of traffic, or to meet volume commitments.

Screenshot "concepts/routing-group-weights" has not been generated yet — see scripts/screenshots/screens.yml.

Add Weighted Distribution to the Routing Policy of the routing group and set a Weight on each entry. The default weight of a new entry is 1. No Value (stored as 0) keeps an entry out of the distribution.

The chance of an entry to come first is its weight divided by the sum of the weights. Three entries with weights 3, 2 and 3 come first in about 37.5%, 25% and 37.5% of calls. The other entries follow in a random order of the same kind, so they are the failover. The choice is made anew for every call and has no memory: the proportions hold over many calls, not over every ten.

The policies of a routing group are applied in their order. Weighted distribution splits that order in three stages:

  1. Policies before Weighted Distribution sort all matching entries.
  2. Weighted Distribution cuts the sorted list into runs. Neighbouring entries with a weight that the earlier policies left equal form a group, and each group is shuffled by weight on its own. Entries with No Value form groups of their own and keep their positions.
  3. Policies after Weighted Distribution sort only inside the No Value groups. The shuffled groups keep their order.

The routing policy is Route Preference → Weighted Distribution → Least Cost:

Entry Preference Weight Cost
Route 1 2 No Value 1
Route 2 3 No Value 2
Route 3 4 2 2
Route 4 4 2 2
Route 5 5 3 2
Route 6 5 4 2
Route 7 6 No Value 3
Route 8 6 No Value 1
Route 9 7 No Value 2

Route Preference sorts the highest preference first: 9, then 8 and 7, then 5 and 6, then 3 and 4, then 2, then 1. Entries with the same preference end up in either order.

Weighted Distribution then forms four groups:

Group Entries Treatment
1 Route 9, Route 8, Route 7 No Value, left for the next policy
2 Route 5, Route 6 (preference 5) Shuffled: Route 6 first in about 4 of 7 calls
3 Route 3, Route 4 (preference 4) Shuffled: each first in about half of the calls
4 Route 2, Route 1 No Value, left for the next policy

Groups 2 and 3 are separate because their preferences differ.

Least Cost finally sorts groups 1 and 4 by cost. Assuming the shuffle kept groups 2 and 3 as they were, the order of the call is:

Position Entry Preference Weight Cost
1 Route 8 6 No Value 1
2 Route 9 7 No Value 2
3 Route 7 6 No Value 3
4 Route 5 5 3 2
5 Route 6 5 4 2
6 Route 3 4 2 2
7 Route 4 4 2 2
8 Route 1 2 No Value 1
9 Route 2 3 No Value 2

Note that Route 8 now comes before Route 9 although its preference is lower: the policy after weighted distribution sorts the whole No Value group.

  • Weighted distribution — splitting traffic between routes by percentage.
  • Routing policy — how a routing group orders and tries its routes.
  • Routing Group — a named set of routing rules assigned to a customer or account.
  • Route — one candidate path for a call: a vendor connection with its priority and cost.
  • Hunting — trying the next route after a failed attempt.

Use Weighted Distribution as the only policy and give the entries weights 7 and 3, or 70 and 30. The first vendor takes about 70% of first attempts; when it fails, the call hunts to the second one, so the second vendor’s real share is higher than 30% if the first one has a low ASR.

Weighted vendors for one destination, least cost for the rest

Section titled “Weighted vendors for one destination, least cost for the rest”

Put a policy before Weighted Distribution that separates the two kinds of entries, such as Route Preference with a higher preference on the weighted routes. Then add Least Cost after it for the No Value entries.