[SR-Users] Dispatcher module and xavp_dst

Pyry Aaltonen pyry.aaltonen at cuuma.com
Fri Sep 2 06:54:56 CEST 2022


Hi,

Thank you for your responses!

I don’t have latency stats enabled, but I do want to have load balance using round-robin by priorities, and that’s why I’m using algo13 instead algo 8, cause algo 8 doesn’t round-robin if the priorities are the same, and still, I do want to have priorities and not only round-robin and that’s why I’m not using algo4 either.
So algo13 should be fine and the dispatching works just like it is described in the documentation, only the xavp_dst values aren’t updated like it should (I think 😊)

Yesterday when I was searching around this issue of mine, I found out this quite recent commit https://github.com/kamailio/kamailio/commit/adba3caa2d12d1f8b89d720fbb9a6a9cdc8b2573
The description of that commit looks quite same that what I’m now facing with only the xavp_dst values.
If the highest priority destination is inactive the destination is updated but the corresponding xavp_dst values are not correct(or missing completely).

With my previous destination examples
If first trunk is inactive, the destination is set correctly to second one, but the xavp_dst values are null, and I think xavp_dst values should be “type=2” or something like that.
10 sip:1.2.3.4;transport=tcp 10 1 type=type1
10 sip:4.3.2.1;transport=tcp 10 1 type=type2

-Pyry



From: sr-users <sr-users-bounces at lists.kamailio.org> on behalf of Julien Chavanton <jchavanton at gmail.com>
Date: Thursday, 1. September 2022 at 16.33
To: Kamailio (SER) - Users Mailing List <sr-users at lists.kamailio.org>
Subject: Re: [SR-Users] Dispatcher module and xavp_dst
The rest of the dispatcher "features", like failover should be supported based on what I remember from the way it was integrated and tested.
If it is not the case I can have a look.


On Thu, Sep 1, 2022 at 9:21 AM Julien Chavanton <jchavanton at gmail.com<mailto:jchavanton at gmail.com>> wrote:
On second thought, the documentation looks accurate to me.
Do you have the latency stats enabled ?
3.26. ds_ping_latency_stats (int)

If yes, the priority values you are using seem a bit low 1ms and 10ms.
If not, the algorithm should behave simply like that :
"The algorithm will load balance using round-robin prioritizing the gateways with the highest priority. "




On Thu, Sep 1, 2022 at 9:09 AM Julien Chavanton <jchavanton at gmail.com<mailto:jchavanton at gmail.com>> wrote:
Maybe the documentation should be improved, it seems the first bullet point should say.

"The algorithm will load balance using round-robin prioritizing the gateways with the highest adjusted priority. "


On Thu, Sep 1, 2022 at 9:06 AM Julien Chavanton <jchavanton at gmail.com<mailto:jchavanton at gmail.com>> wrote:
Hi, did you look at the documentation of  algorithm 13 ?

The priority is used in combination with the latency to determine the preferred gateway.
Once you confirm that this is what you want "latency latency optimized dispatching", we can help to clarify why and how this may not work as expected.

Regards


https://kamailio.org/docs/modules/devel/modules/dispatcher.html

  *   “13” - latency optimized dispatching

- The algorithm will load balance using round-robin prioritizing the gateways with the highest priority.

- If ds_ping_latency_stats is active the algorithm will adjust the priority of the gateway automatically, the priority will be lowered by 1 point every time the latency ms is as high as the priority.

- If the attribute 'cc=1' is set, the latency used is congestion ms : estimate (current latency ms) - average (normal condition latency ms).

Example 1.46. latency_optimized_dispatching usage

Using this simple formula :

    ADJUSTED_PRIORITY = PRIORITY - (ESTIMATED_LATENCY_MS/PRIORITY)



GATEWAY | PRIORITY | ESTIMATED | ADJUSTED | LOAD

   #    |          |  LATENCY  | PRIORITY | DISTRIBUTION

   1    |    30    |    21     |    30    | 33%

   2    |    30    |    91     |    27    | 0%

   3    |    30    |    61     |    28    | 0%

   4    |    30    |    19     |    30    | 33%

   5    |    30    |    32     |    29    | 0%

   6    |    30    |    0      |    30    | 33%

   7    |    30    |    201    |    24    | 0%





With congestion control the formula becomes :

    CONGESTION_MS = CURRENT_LATENCY_MS - NORMAL_CONDITION_LATENCY_MS

    ADJUSTED_PRIORITY = PRIORITY - (CONGESTION_MS/PRIORITY)


  *

On Thu, Sep 1, 2022 at 2:38 AM Pyry Aaltonen <pyry.aaltonen at cuuma.com<mailto:pyry.aaltonen at cuuma.com>> wrote:
Hello,

I’m quite new user with kamailio (heard first time about it a year ago and joined the list yesterday) and now wondering how the xavp_dst should work.

I had read from the documentation that
”The first XAVP is the current selected destination.”

I use ds_select_dst with alg 13. And my kamailio version is kamailio 5.5.3 (x86_64/linux)

So when my dispatcher list is like (I have also tried to differ the priority value like 10 and 1, but doesn’t make difference)
10 sip:1.2.3.4;transport=tcp 10 1 type=type1
10 sip:4.3.2.1;transport=tcp 10 1 type=type2

If one of the destinations fails (dx/ip), and it happens to be the one with higher priority or the one that just gets higher position in the dispatcher list if the prio Is equal.
My xavp_$xavp(dsdst=>attrs) get null value. And, if I try to seek $(xavp(dsdst[0]=>attrs) or $(xavp(dsdst[1]=>attrs) I also got nothing.

If both destinations are up with equal priority, it selects them with round-robin, and the xavp_$xavp(dsdst=>attrs) has the type value of the selected destination as expected, also the $(xavp(dsdst[0]=>attrs) or $(xavp(dsdst[1]=>attrs) contains the destinations so that the selected is 0 and the other is at position 1.
The $du is updated as I expect so if one fails the other one is selected always, why the xavp_dst isn’t working same way, or am I missing something?

If needed I’ll try to provide more information,
Thanks already in advance

-Pyry








__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220902/3db62abb/attachment.htm>


More information about the sr-users mailing list