[SR-Users] Dispatcher flow regarding weight and priority.

Dmitri Savolainen savolainen at erinaco.ru
Mon Dec 11 15:38:36 CET 2017


Hi, Joel!

You may  call ds_select_dst for two sets:
set 1 with 1.1.1.1  ds_select_dst("1", "4")
set 2  with 2.2.2.2 and 3.3.3.3. If set1 is down (ds_select_dst("1",
"4")==false)  then try ds_select_dst("2", "9")




2017-12-07 20:47 GMT+03:00 Joel Serrano <joel at gogii.net>:

> Hi all,
>
> I have a doubt regarding how dispatcher selects a node...
>
> From the docs:
>
>
> *[...]*
> *alg* - the algorithm used to select the destination address. The
> parameter can be an integer or a variable holding an interger.
>
>
>    -
>
>    “4” - round-robin (next destination).
>    -
>
>    “8” - select destination sorted by priority attribute value (serial
>    forking ordered by priority).
>    -
>
>    “9” - use weight based load distribution. You have to set the
>    attribute 'weight' per each address in destination set.
>
> *[...]*
>
>
> I normally use "4", so dispatcher round-robins through the destinations of
> a setid, but I have now the following doubt:
>
> If a trunk has 3 nodes, say 1.1.1.1, 2.2.2.2, 3.3.3.3
>
> Can I do:
>
> Send all calls to 1.1.1.1, if it goes down, then do a 80%-20% between
> 2.2.2.2 and 3.3.3.3.
>
>
> if the trunk has a correct DNS SRV setup with weight and priority it's
> easy to achieve, but in this case there is no SRV or nothing, just 3 IPs.
>
> So can this logic be achieved with dispatcher directly? Can do some
> combination of alg "8" and alg "9"?
>
> Or would the correct approach need two separate setid groups and handle
> that logic in failure route?
>
>
>
> Thanks,
> Joel.
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>


-- 
Savolainen Dmitri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171211/02e56b24/attachment.html>


More information about the sr-users mailing list